atw: Re: Dealing with SMEs?

  • From: Stuart Burnfield <slb@xxxxxxxxxxxxxx>
  • To: Austechwriter <austechwriter@xxxxxxxxxxxxx>
  • Date: Wed, 11 Mar 2009 10:01:00 +0900 (WST)

Good advice so far. Some more thoughts: 

- It's better to go in with a tentative understanding and get the SME to 
correct or elaborate it. Ideally you shouldn't go into a session just to be 
pumped full of new information. It's very hard to understand complex material 
without having time to go over it in your mind. 
- Try to develop a 'big picture' that you gradually expand and refine as you 
find out more. Early on it might just be a one-page diagram or a few sets of 
bullet points. As you learn more you might expand each bullet point or blob in 
the diagram into a paragraph. After a while it should cover things like the 
purpose of the project/product; its main features/functions; main 
industries/markets/competitors; main users; their tasks and goals. Think of 
this as the overview or plan of attack that would have liked to have when you 
started on the project--a survival guide for your younger self. From time to 
time, check this understanding with your manager and the SMEs. This will be 
your solid ground when you go on to drain new areas of swamp. 
- Remember that your SMEs have probably been immersed in the project for some 
time and they may have been grappling with complex, low-level details when you 
come to see them. It's hard for anyone in that situation to step back and give 
the to someone who's new to it. 
- Don't try to chase down every unfamiliar concept while you're talking to an 
SME. There will always be jargon that you don't understand. You need to develop 
a sense of when to jot down an acronym and keep listening, when you need to 
stop the SME and ask for clarification, and when something unfamilar is 
probably not relevant to you so you can just ignore it. 
- A lot of people pooh-pooh Wikipedia but it's a great resource for technical 
concepts when you're starting from zero. 

I can recommend this excellent book: 
_User and Task Analysis for Interface Design_, by Hackos and Redish 

Plenty of guidance on how to gather and organise information. Don't be put off 
by the name--it's equally applicable to tech writers. 

Good luck. 

Stuart 

Other related posts: