Form Follows Function

Fred Williams explains the importance of putting functionality before structure in software development. (Prague, 23.4.2015)

Two Tests For Software

You should always be able to define two tests for any software feature…the user value, and the business value (Prague, 8.4.2015).

Put users first

If you create a system, then look for users, you’re doing it backwards. Instead, you should define your users and their desires so you can solve real world problems. (Prague, 1.4.2015)

Make Software For People

Remember that in the end your software must perform real world functions for real people.  So start with understanding your users and what they want to achieve.  You’ll be more successful.

What makes Williams Technical Different?

Fred surrepticiously looks at his notes as he tries his best to be serious…because Williams Technical is seriously different. We focus on people and processes, making sure goals are understood so we’ll work together on what matters most. (Prague, 2011)

There’s No Ideal Project

Too often, developers put documentation off to the end of the project, and then it’s a mad scramble to provide even basic user instructions. Here’s what you can do…(Prague, 2013)

Exageration and Ambiguity

If you cannot measure it, or define it, then you cannot test it. If you cannot test it, how do you know it’s correct? What is “it” anyway…Fred talks about avoiding exageration and ambiguity. (Prague, 2011)

What are the Key Skills of a Technical Writer?

Empathy, confidence and honest curiousity matter as well as good writing and then technical skills. (Prague, 2013)

Writing for User Personas

Know your audience…how do describe YouTube to 70 year old Mildred Thistlebottom? (Cologne, 2010)

Testing Requirements

If you cannot test a user requirement, then it’s not valid. Here’s how Fred describes how to write requirements and test cases together.

Choosing Terminology

Use the language of your users. (Cologne, 2010)

Writing Requirements

How to write Waterfall type requirements, using imperatives and “stong” versus “Weak” modals. (Cologne, 2010)

Levels of Detail in Technical Documentation

Who wants to read about what? Users, Administrators, and developers have differing interests. (Cologne, 2010)

Documentation Patterns

User documentation. What, where, why, when, and who should use the feature. How do they do it? What should they expect as the result? (Cologne, 2010)

Active Voice – Cats Eat Rats

Avoid the passive voice. Here’s a way identify passive English, and change it into clear active voice in the simple present tense. (Cologne, 2010)

Intro to Technical Documentation – structuring information

Fred gives the outline of a “typical” user instruction, with Description, Steps, and Outcome. (Prague, 2011)

The A.A.R.T. of Writing User Stories

Presentation at Agile Conference Prague : The A.A.R.T. of Writing User Stories (September 2013)