This document provides guidelines for designing consistent and usable user interfaces. It recommends striving for consistency in areas like color, layout, fonts and behavior. It also suggests providing informative feedback to users, preventing errors through careful defaults and validations, and allowing for easy reversal of actions. The document advocates keeping users in control and reducing memory load. It notes the importance of consistency, preventing errors, and providing feedback in interface design.

1. Awalin Sopan
Sr. Software Engineer, FireEye Inc.
@awalinsopan

2.  Strive for consistency
 Seek universal usability
 Offer informative feedback
 Design dialogs to yield closure
 Prevent errors
 Permit easy reversal of actions
 Keep users in control
 Reduce short term memory load
https://www.cs.umd.edu/users/ben/goldenrules.html
Designing the User Interface, 6th Edition

3.  Consistent:
 Color
 Layout
 Font
 Visual hierarchy
 Behavior
 Behavior:
• If clicking a table row expands the row,
do it in all tables.
• Error message/ instructions should be
consistent and clear.
• Input forms and formats.
• Navigation: internal vs external links.

4. Visual hierarchy with font size and layout

5.  Feedback:
 Tell the users in place what they are doing wrong and how to fix it.
https://www.nngroup.com/articles/affordable_care_act_usability_issues/

6.  Prevent Errors:
 Be proactive than reactive:
 tell the users the expected password pattern beforehand.
 Carefully chose defaults.
 Easy Reversal:
 Don’t make the users retype everything for one mistake.

8.  Move fast.
 May ignore user research/ usability testing.
 If they have UX, UX must be at least 1 sprint ahead of development.
https://www.nngroup.com/articles/doing-ux-agile-world/

9.  Leverage frameworks/ open source tools:
 Layout: Bootstrap
 Validation: http://formvalidation.io/

10.  Developers:
 White boarding/ sketching / low fidelity mockup.
 Make quick UI prototype.
 Get feedback before all functionality are completely written.
 Are well informed about UI standards.
 Part of user story writing.
 Deploy prototype in server for quick feedback.

11.  Consider UI Review like Code review.
 Code does not go to production unless UI is
approved by team.
 Involve QA in testing UI standards:
 If UI principles are broken, QA should report
a bug.

12.  Central repo/documentation of UI standards
 With examples.
 For both developers and testers.

13.  Write UI components/widget library:
 Reusable
 Dynamic/ Configurable
 Extendable:
 DialogView can extend ModalView.
 TreeView can be a subclass of GraphView.
Write a UI widget class:
What are the properties?
How does it look?
How does it behave/
how do users interact with this
component?

14.  Iterative process.
 Everyone involved.
 Quick and continuous feedback.
awalin.sopan@fireeye.com