From the University of Illinois Web Conference 2013. Ask a web designer who his “first users” are, and he’ll probably name early adopters, stakeholders, or usability testers. Designers rarely consider their actual first users: the web developers they work with to build their designs. Over the last year, I’ve performed an informal user research project where the “users” were software development teams of all shapes and sizes. Drawing on these discussions and my background as a former web developer, I’ve created a set of friendly heuristics (in the tradition of Jakob Nielsen and Louis Rosenfeld) that designers can use to make their design materials far more useful for developers. I’ll show how these heuristics will encourage holistic solutions rather than piecemeal design work, surface critical implementation issues sooner, and establish a stronger basis for designer/developer collaboration.

1. First Users:
Designing for Web Developers
Heuristics for improving
designer/developer collaboration
UIllinois Web Conference 2013
Jonathan Abbett
@jonabbett · jonathan@abbett.org · http://abbett.org

2. Questions?
Critiques?
Suggestions?

3. 24 December 1990

5. The CONCISE FOLK HISTORY of “WEB PEOPLE”
Webmaster
Information Architect

7. The CONCISE FOLK HISTORY of “WEB PEOPLE”
Webmaster
Information Architect
Web Designer
Web Developer
Usability Analyst
Interaction Designer
User Experience Designer
Content Strategist
JavaScript MVC Developer, etc., etc., etc.
vs. “The User”

8. 1990
JAKOB
NIELSEN
10 Usability
Heuristics
for User
Interface
Design
2011
RESMINI &
ROSATI
Heuristics
for a
Pervasive
Information
Architecture
2011
JUHAN
SONIN
Design
Axioms
2012
ABBY
COVERT
Information
Architecture
Heuristics
2004
LOU
ROSENFELD
IA
Heuristics

9. The CONCISE FOLK HISTORY of “WEB PEOPLE”
Webmaster
Information Architect
Web Designer
Web Developer
Usability Analyst
Interaction Designer
User Experience Designer
Content Strategist
JavaScript MVC Developer, etc., etc., etc.
vs. “The User”

11. “Designers have to be aware that what is
‘normal’ to them, in terms of how they read
sketches and what they see in them, is not
obvious to others, and they must take that
into account in how they educate others, and
what representation they use to
communicate ideas.”

12. “Those without design training … need to be
sensitive to this difference of skills … before
making uninformed judgments... [They]
should do their best to gain some literacy in
design representations, and designers should
go out of their way to help them in this.”

13. A common language

16. Intentionality
Consistency
Thoroughness
Inforealism
Adaptation
Maintenance
Measurability
Communication

17. ONE / INTENTIONALITY
All design choices are made for a
reason.

18. ONE / INTENTIONALITY / KEY QUESTIONS
• What user/business/communal goals are served by
each component of the design?
• Are design decisions supported by best practices?
• Do you understand why you’ve copied something
from elsewhere?

19. ONE / INTENTIONALITY / IN ACTION
• Annotate design materials with references to user
research (scenarios, personas, etc.)
• Refer to known design patterns, best practices, or
heuristics
• Present new interactions for team critique
• Simplify!

20. TWO / CONSISTENCY
The same interactions are
represented the same way
throughout the design.

21. TWO / CONSISTENCY / KEY QUESTIONS
• If recommending an alternative to an established
interaction pattern, why is this new type of
interaction necessary or desirable?

22. TWO / CONSISTENCY / IN ACTION
• Define visual treatments (type, color, layout
patterns) in one place and use consistently
throughout design materials.
• Define frequently used interactions once in detail,
and refer back when used in designs.
• Justify differences (see #1)
• Create templates so you can work quickly without
being sloppy

23. THREE / THOROUGHNESS
The design comprehensively
represents all system states,
transitions, and modes of
communication.

24. THREE / THOROUGHNESS / KEY QUESTIONS
• Does the design include examples of all interaction
states?
• Does the design show transitions from one state to
another?
• Has the software team agreed that it has enough
detail to build?

25. THREE / THOROUGHNESS / IN ACTION
• Wireframe in sequence
• Review materials with devs and annotate directly
• Prototype unfamiliar or complex interactions in a
more realistic medium
• Don’t forget errors, delays, service interruptions,
validation
• Supplement visual materials with software
requirements if necessary

27. FOUR / INFOREALISM
The design fully reflects the data to
be displayed and captured.

28. FOUR / INFOREALISM / KEY QUESTIONS
• Are designs and prototypes populated with real
data?
• Do you understand the extremes of your data?

29. FOUR / INFOREALISM / IN ACTION
• Get access to your company’s data (now).
• Look at extremes of individual fields.
• Look at overall orders of magnitude.
• Include examples of missing/absent data.
• Take time to write real copy. No lorem ipsum.

30. FIVE / ADAPTATION
The design indicates how the system
will adapt to different form factors.

31. FIVE / ADAPTATION / KEY QUESTIONS
• What devices, browsers and screen orientations will
you support?
• Will you implement one responsive interface, or
specialized interfaces?

32. FIVE / ADAPTATION / IN ACTION
• Wireframe every relevant form factor (at least at a
high level, e.g. layouts).
• Build responsive prototypes.
• Identify which user scenarios require mobile device
access.
• Remember accessibility! (Screen readers, etc.)
• Mobile first…
http://www.lukew.com/presos/preso.asp?26

33. SIX / MAINTENANCE
The design describes how the user
will administer the system.

34. SIX / MAINTENANCE / KEY QUESTIONS
• What data elements need to be managed?
• How will you monitor system health?
• How will the right people compose content? (help,
marketing, field labels, validation)
• How will you internationalize the content?
• What system scenarios require proactive
notification?

35. SIX / MAINTENANCE / IN ACTION
• Design all administrative interfaces up front.
Don’t leave for the end.
• Bring content writers (customer service, marketing,
content strategists, etc.) into process early.
• Remember that i18n can be employed for low-
literacy users.

36. SEVEN / MEASURABILITY
The design specifies what measures
will be collected to indicate the
success of the system.

37. SEVEN / MEASURABILITY / KEY QUESTIONS
• How will product owners track operational success?
• How will you gauge success of redesign over legacy
design?
• How does the design communicate those measures?

38. SIX / MEASURABILITY / IN ACTION
• Design reports and analytical tools up front.
Don’t save it for the end.
(In fact, you might want to start here.)
• Define your [design] success criteria.
• Refer to user goals & corporate goals.
(You have them, right?)

39. EIGHT / COMMUNICATION
The design specifies how the system
will communicate with users
throughout the product experience.

40. EIGHT / COMMUNICATION / KEY QUESTIONS
• Does the design include real & thoughtful content?
• What synchronous & asynchronous events within
the application will trigger communications?
• What mode(s) of communication are appropriate
for each event?

41. EIGHT / COMMUNICATION / IN ACTION
• Again, no lorem ipsum: write real informational,
instructional/help content.
• Design & test your e-mails (e.g. Litmus)
• Think across spectrum: growl, popup, e-mail, text
message, automated phone call, snail mail…
• Understand your users’ technology access
(e.g. smartphone vs. SMS)

42. Ways to use
1. Add a step in your process for review.
2. Use as a kickoff document for projects with
new teams.
3. Teaching tool, alongside other heuristics
4. Dismiss as common sense (at your peril)

44. With thanks to these
developers and designers
William Wechtenhiser, Jeremy Hert, Timothy Danford,
Chaim Kirby, Flavia Gnecco, Patrick Keller,
Patrick Schmid
And recognizing great inspiration from
Juhan Sonin, Abby Covert, Atul Gawande,
Bill Buxton, Alok Nandi

45. Thank you!
http://devheuristics.com
@jonabbett
jonathan@abbett.org

46. References & Resources
JAKOB NIELSEN: 10 Usability Heuristics for
User Interface Design
http://www.nngroup.com/articles/ten-usability-
heuristics/
RESMINI & ROSATI: Heuristics for a Pervasive
Information Architecture
http://pervasiveia.com/wp/wp-
content/uploads/2011/04/chapter3-heuristics.pdf
JUHAN SONIN: Design Axioms
http://www.mit.edu/~juhan/design_axioms.html
ABBY COVERT: Information Architecture
Heuristics
http://www.slideshare.net/AbbyCovert/information-
architecture-heuristics
LOU ROSENFELD: Information Architecture
Heuristics
http://louisrosenfeld.com/home/bloug_archive/000286
.html
BILL BUXTON: Sketching User Experiences
http://www.billbuxton.com/
ATUL GAWANDE: The Checklist Manifesto
http://gawande.com/the-checklist-manifesto

47. Image Sources
WorldWideWeb browser: http://www.w3.org/People/Berners-Lee/WorldWideWeb.html
Nielsen: http://jakob.nielsen.usesthis.com/
Rosenfeld: http://www.flickr.com/photos/jodieandlarry/1386993480/
Sonin: http://about.me/juhansonin
Resmini: http://uxbrighton.org.uk
Buxton: http://billbuxton.com/