Communicating Functionality

How does a technical writer and developer communicate how a product works to a user? How do they communicate functionality, to make their audience’s user experience easier? They plan it out by knowing their audience, knowing what is expected of the product through meetings and through training.

Knowing the audience

Create the product needed by the user.

  • What does your user need to know- what do they already know?
  • Does the developer know how much information a user knows and more importantly, what is needed by the user in order to develop applications that are suitable for them? For example, do menu options need to be displayed?
  • Does the technical writer need to write lengthy documents or just quick sheets?

Knowing what is expected

The answer to many questions is by having all parties share their knowledge through meetings. The technical writer, as mediator, interviews each party, and gets answers to questions, such as:

  • What will the product do and why?
  • Will the product be suitable for the user?
  • Will it be intuitive or data driven?
  • Will the technical writer have to write a long procedure?
  • Will this be on the web? Web-based applications are easier for users to access and use. Documentation will also be easier as help menus (with hyperlinks) can be created.
  • Will this be an end-user product? – If so, then documentation will be lengthier unless the product is easy to use and mostly error free. – Note: To avoid frustrating user errors, multiple options can be listed to avoid this problem.

Knowing what training is needed

The best product or application for a user as a whole should not be complicated.

  • If a product or an application is complicated or has a lot of options, then the technical writer can develop business cases with user stories to help with explanations. The writer can also create training sessions with demonstrations and/or create instruction videos that are not too complex. Images are always better than words. Words however should still be written to reinforce what was presented.
  • If an application is, for example, a data entry form, the user should be able to go through the mechanics without problems – in other words, it should instinctively lead the user to the next screen or item without any extra work nor thought from the user.

Key words are: ‘what is needed, shared, and not complicated’. To communicate functionality to the user, know what is needed, be aware of what they already know, and know how best to present it. Make sure that communication exists between all parties through meetings. Knowing how much to document will also depend on the results of these meetings. As always, when verbally communicating or writing, stick to the point; be concise and accurate.

If you have any suggestions or comments on how to communicate functionality to make a user’s experience more enjoyable and easier, please leave a comment. Thank you