In this presentation the speakers will discuss the methods and strategies of writing technical communication in the design of software for the government sector with the broader goal of evaluating best practices for how to create a positive user experience for a particular user group. Creating software for the government, and specifically in defense contracting, involves understanding a specific set of user needs and a variety of command and control net-centric contexts ranging from real-time analytics, cyber-situational awareness, to strategic and operational planning. The best practices for designing and writing for such a diverse set of needs involves tight integration with the software development team, stakeholders, and users such that the right words and elements are incorporated into the interface and that the technical documentation properly reflects the software’s features. The presenters will further discuss examples of content strategy driving from their industry experience and expertise.

1. Designing
to Save
Lives:
Government
Technical
Documentation
Laurian Vega
Stephanie Saylor

2. “I'm a great believer that any
tool that enhances
communication has profound
effects in terms of how
people can learn from each
other, and how they can
achieve the kind of freedoms
that they're interested in.”
Bill Gates

3. Important things HealthCare.gov improved
in response to public comment:
1. A clear starting point
2. Identify the critical path
3. Include key details
4. Explain requirements for username
and password
5. Write understandable error messages
http://usability.com/2013/11/usability-testing-healthcare-gov/

4. Your words makes a difference.
• Email alerts
• Error messages
• Page placement
Putting it in
perspective

5. User Characteristics
● They are fulfilling a need to serve.
● They function and action in a
military, top-down chain of
command.
● They are divided across numerous
systems with different access
privileges; they have multiple
monitors.
● They have varying levels of
education & reading levels.
● They can easily become myopic
and tightly focused.

6. Our users
work in
command
and control
net-centric
contexts
Real-time
analytics
Cyber-
situational
awareness
Strategic
and
operational
planning

7. Our users
work in
command
and control
net-centric
contexts
Real-time
analytics
Cyber-
situational
awareness
Strategic
and
operational
planning

8. Our users
work in
command
and control
net-centric
contexts
Real-time
analytics
Cyber-
situational
awareness
Strategic
and
operational
planning

9. CODE
To translate a design specification
into a computer program through
composing computer code.
TEST
To evaluate a design, document, or
code to ensure that it meets the
specifications outlined in the analyze
and design phase.
ANALYZE & DESIGN
To formulate the needs of the user,
customers, and other stakeholders
into a meaningful specification that
can be understood and translated.

10. Agile Software Development, UX, and Technical
Documentation
Lindsay Ratcliffe, Marc McNeill. 2011. Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous

11. Software Development Sprint

12. Software Development Sprint UX Development Sprint

13. Software Development Sprint Technical Writing Sprint

14. I track my day to
make sure I know:
● What is critical?
● How much time I
have?
● What to review the
next day during
scrum?
Extremely necessary if
split across more than one
project.
http://davidseah.com/blog/node/the-emergent-
task-planner/

15. Having one place to access all of
the graphics, mock-ups, testing
results is one of the most time-
saving and team-building
activities you can do.

16. Make sure that you post
links to your wiki where
resources are needed to
team scrum boards.

17. I hold weekly brown bag
lunches
● I review what mock-ups
I’ve made or the outcomes
of user interaction
● I pass out post-it notes and
ask people to write their
questions, comments,
opinions on them
(anonymously)
● I collect (and sometimes
sort) the post-its and
updated mockups

18. 1
2
3
You Can Start Fresh
You Work on New Features
You Cannot Touch Anything

19. If you can start
from scratch
1. Look at what
other tools are
out there.
2. Create mockups
3. Test
4. Show hi-fi mock-
ups to customers
5. Create style-
guide
6. Work to
implement
7. Test again
http://healthmap.org/en/

20. If you can start
from scratch
1. Look at what
other tools are
out there.
2. Create mockups
3. Test
4. Show hi-fi mock-
ups to customers
5. Create style-
guide
6. Work to
implement
7. Test again
http://healthmap.org/en/

21. If you can start
from scratch
1. Look at what
other tools are
out there.
2. Create mockups
3. Test
4. Show hi-fi mock-
ups to customers
5. Create style-
guide
6. Work to
implement
7. Test again
http://healthmap.org/en/

22. If you can start
from scratch
1. Look at what
other tools are
out there.
2. Create mockups
3. Test
4. Show hi-fi mock-
ups to customers
5. Create style-
guide
6. Work to
implement
7. Test again
http://healthmap.org/en/

23. If you can start
from scratch
1. Look at what
other tools are
out there.
2. Create mockups
3. Test
4. Show hi-fi mock-
ups to customers
5. Create style-
guide
6. Work to
implement
7. Test again
http://healthmap.org/en/

24. If you can start
from scratch
1. Look at what
other tools are
out there.
2. Create mockups
3. Test
4. Show hi-fi mock-
ups to customers
5. Create style-
guide
6. Work to
implement
7. Test again
http://healthmap.org/en/

25. If you can start
from scratch
1. Look at what
other tools are
out there.
2. Create mockups
3. Test
4. Show hi-fi mock-
ups to customers
5. Create style-
guide
6. Work to
implement
7. Test again
http://healthmap.org/en/

26. If you can’t start from scratch.

27. If you can’t start from scratch, you polish and work with what you
have.

28. If you can’t
start from
scratch, you
make it shine.

29. Mandatory
Words
When you’re
required to include
links, logos, catch
phrases, etc., find
creative ways to
highlight
important
information.

30. Mandatory
Words
An example of an
Institute following
the example of its
parent
organization.

31. Mandatory
Words
User the footer!

32. Mandatory
Words
Make the footer
useful.

33. Mandatory Words

34. No touching!
What if you can’t change
the site/application?
• Make tools that help users
navigate it.
o Training guides, wikis, help
videos
• Propose solutions to the people
that can change it.
o Support those solutions
with research and plans

35. Getting Started
1. USER RESEARCH
Know your users’ habits, tools, and
access levels
2. PROBLEM RESEARCH
Play anthropologist--track down why
your product doesn’t work for your
users
3. CUSTOM HELP
Use your new info to help users in
the way they want to be helped

36. Step 1: User
Research
● Know your users:
○ How they work?
○ How they use your
product/website?

37. Step 2: Problem
Research
● Know their roadblocks:
○ What frustrates them?
○ How do they
troubleshoot?

38. ● Use available resources
○ Anyone who has used the
product
○ Anyone who has worked on
the project
○ Network drives
○ FAQs
○ “Contact us” email repository
Step 2: Problem
Research

39. User Knowledge → How to reach
your users
Problem
Understanding →
What they
need to
know
Step 3: Help Users

40. You won’t find a universal
answer about what kind of
tools to use.
Use the method that works
best for your users:
wikis, PDF user guides, online help systems,
intranets, training videos, knowledge bases, etc.
Step 3: Help Users, Tools

41. • Active voice
• Use plain language
• Talk to people, not at them
• Think about translation
• Bullets and lists
• Infographics
• Ban crutches
Step 3: Help Users, Writing

42. Step 3: Help
Users,
Writing

43. Good Examples
“Read everything--trash, classics,
good and bad, and see how they
do it. Just like a carpenter who
works as an apprentice and studies
the master. Read! You'll absorb it.
Then write. If it is good, you'll find
out.”
~William Faulkner
• http://centerforplainlanguage.org/awards
• govtech.com
• http://www.nih.gov/clearcommunication/
plainlanguage.htm

44. Specific Government
Challenges
• Stovepipes
• Constant internal
competition
• Funding uncertainty
• Bureaucratic mindset

45. Solutions
• Workarounds
• Plans
• Make your boss’s
boss look good
• Focus on small wins
Don’t give up!

46. Closing Remarks
• Find your voice...don’t let it be
passive
• Read great technical writing
o Ginny Redish Letting Go of
the Words
o Steve Krug Don’t Make Me
Think
o O’Reilly’s Head First series
My hero: Technical Communication
Rock Star Ginny Redish

47. Thank you
Questions?
Laurian Vega, Laurian.Vega@NextCentury.com
Stephanie Saylor, Stephanie.Saylor@NextCentury.com

48. Huge usability reports rarely
get read and reused. We
recommend a quick and
dirty approach to usability
reports.
1. Make a bulleted list of
all usability problems/
wins.
2. Affinity diagram all to
create categories
3. Brainstorm solutions to
each.
4. Create cards that have
name, description of
the problem, and an
image.

49. Resources
• http://centerforplainlanguage.org/awards/clearmark2013/
• http://www.govdelivery.com/blog/2013/10/great-government-websites-benchmarking-the-best-2/
• http://www.govtech.com/cdg/digital-government-achievement/