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)
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.
Use the language of your users. (Cologne, 2010)
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)
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)