Skip Navigation LinksHome > SSW Standards > Rules To Better Interfaces

I've been putting together Development Guidelines for my employer and in the process have reviewed many published standards (in the .Net arena) from around the world. In each category, the suggestions at SSW are always among the best. Leon Bambrick -
 

Introduction

What is software?
From a technical perspective, a piece of software comprises forms for managing, collecting and transmitting data. But that is not what a user thinks.
From the user's perspective software is a computer tool for performing tasks quickly, efficiently, accurately and with a minimum amount of cognitive demand.

Aim for the second one, there's a big difference.

The whole point of a good GUI (Graphical User Interface) is being able to understand what is going on without reading every single detail. That is why we prefer big red crosses to say "Don't do that you oaf!" instead of a line of text that says "I think you may want to reconsider your options."

Do you agree with them all? Are we missing some? Let us know what you think.

  1. Do you realize that a good interface should not require instructions?

    The corner stone of good user interface design is that if your users need instructions, you haven't done a good job. Of course with particularly complex applications there will be exceptions to this rule, but all developers should aim to make your interface as self evident as possible.

    • There are no surprises
    • There is no need to use help
    • No excuse for RTFM (read the freaking manual)
    Figure: A good interface does not need instructions!

    A good UI is:

    • Intuitive
    • Feels fast - eg. no white screen, threading code
    • Consistent
    • Minimal popups
    • No clutter - not busy
    • Good error handling
    • Easy to customize + apps (aka a platform)
    • Gamification eg. badges
    Team Viewer Interface
    Good example: Teamviewer's interface requires very little explanation
    Fly in a Urinal
    Figure: Good Example - See the fly? (an example of excellent usability) Dutch manufacturers realized that a fly painted on the urinal became a "target" for men using the facility. And the fly is positioned in precisely the right place for minimal spillage or splash back. Clever people those Dutch!
  2. Do you make users intuitively know how to use something?

    1. When we see a door, we immediately know that we can open it and go through it
    2. Links in blue and underlined has an affordance of clickability
    3. Buttons can be pressed
    4. Scrollbar moves the document in the window
    False affordance
    Figure: The affordance of the checkbox makes this UI misleading
    False affordance
    Figure: Bad Example - If this mop sink didn't look so much like a urinal and wasn't right next to the toilet, maybe the sign wouldn't be necessary.
    False affordance
    Figure: Figure: Bad Example – It might not have been a good idea to place a male policeman where the exhaust pipe is.
    False affordance
    Figure: Old MS Word - Because of the UI, people never knew how to use styles
    Figure: New MS Word - Because of the UI, people know intuitively how to use styles
  3. Less is More - Do you realize that when it comes to interface design 'less is more'?

    'Less is more' is the idea that simplicity and clarity lead to good design. The interface design is an attempt to solve the problem of how to communicate clearly.

    How to make a user interface great:

    • Less is more - keep your design as simple and uncluttered as possible
    • Understand the importance of defaults - Aim for 'Next', 'Next', 'Next'
    • Hide advanced options, but make them easy to find!

    Most developers think about user interface last. They spend their time worrying about class design, threading, and system architecture. All this is important, of course. But the user only experiences software on the surface level.

    It might be fantastic under the covers, but if the user interface is not intuitive the user will think the application is just hopeless. If the user interface doesn't afford an easy and simple understanding of how to operate the application, you'll get a lot of unhappy customers and unnecessary support calls.

    Do yourself a favor, take some time to think about UI first.

    Bad UI Example
    Figure: Bad Example - An example of a poor UI
    Bad UI Example
    Figure: Bad Example - Functional overload (a programmer probably designed this one)
    Bad UI Example
    Figure: Bad Example - Another example of Functional overload
  4. Do you know how to use "gamification"?

    "Gamification" is a method of encouraging user participation. Usually these are a set of fictional incentives such as points or achievement badges.

    It originated with Frequent Flyer programs and has crossed over into the software world with the success of FourSquare.

    This concept is being utilized even in Visual Studio.

    MSDN Screenshot
    Figure: Good Example – MSDN allows users to score achievement points
    Stack Overflow Screenshot
    Figure: Good Example – Stack Overflow uses reputation points, awarded by how useful your answer to other user submitted questions were
  5. Less is More - Do you know people visually map (and scan, not read)?

    People rarely read word by word; instead, they scan the page, picking out individual words and sentences that seems more relevant.

    It is important to divide information, not show it all at once. The visual organization of information is vital to legibility. When displaying information or controls, designers need to visually convey:

    1. Information structure
    2. Relation between elements
    3. Importance and relevance of elements
    Bad information
    Bad example: Can you find how to check in?
    Good information - this alt text makes no sense but do I look like i care; no. maybe the guys in china have the right idea, do a shit job of it and no one will ever bother you about it ever again.
    Good example: What about here? Can you find how to check in?
    Figure: Bad Example - Which is the dial that controls the top-right stove?
    Figure: Good Example - In this layout, it's easy to see which dial controls which stove

    This also applies to text, read our rule on Messages - Do you use messages that are concise and informative?

  6. Less is More - Do you always try to reduce complexity?

    The human brain:

    1. Never searches for OR compares all options
    2. Prefers smaller sets of options (4 or less)
    3. Picks the first option that looks good enough
    4. Prefers a shorter option to a longer one
    5. Makes a compromise between speed and accuracy

    It's important to keep these in mind when making design decisions or presenting data.

    Our visual short term memory has a capacity of 4 items. So options are easier for our brain to digest when presented in sets of 4.

    Adobe Illustrator
    Figure: Blocks of 4 or less menu items are easier for the brain to consume
    Adobe Illustrator
    Figure: Even though the iPad has a larger screen estate, it still uses a max of 4 icons across
    Good Interface Design Example
    Figure: Good Example - A great example of removing complexity.
  7. Do you know how to use storyboards?

    Complex documentation can waste time. Many user requirements can be best encapsulated in screen mock-ups. Spend more time on mockups compared with time on documentation.

    Read more about storyboarding

  8. Do you have a "search box" to make your data easy to find?

    Easy to search
    Good example: a "search box" makes it easy to find data
  9. Do you consider optical alignment?

    Optical alignment
    Figure: In the first example, although the text is technically aligned, it does not 'look' it. In the second one, the "V" has been moved into the margin, but the optical alignment is now correct

    Not only relevant in typography, optical alignment can also be used in forms and web.

    Bad alignment
    Bad example: The fields are aligned to the radio buttons, but it does't "look" good enough
    Good alignment
    Good example: It seems neater, even though it is no longer technically aligned
  10. Do you highlight incomplete work with red text?

    It is important that users of your application who provide feedback have very clear indications of work that is not yet complete, to avoid feedback on sections of your application that are still under development.

    Also, see our rule on color usage in windows forms.

    Figure: Bad Example ?A tester or a product owner who comes to this page may believe that it is broken, or that the developers have 'missed' it. Always be clear about what parts of your application are not yet ready for feedback
    Figure: Good Example ?It is clear to testers and to the product owner that this page is incomplete, but they can get more details from the product backlog
    Figure: Best Example ?Use feature toggles to not show incomplete elements to testers or product owners. See FeatureToggle by Martin Fowler. Feature Toggling can require a large amount of extra work and so is often only implemented by teams with a need to ship features while others are still in development
  11. Column Data - Do you make matrix columns as simple as possible?

    Bad alignment
    Bad example: Hard to read these columns
    Good alignment
    Good example: The whole table has been re-written and is now easier to understand
  12. Column Data - Do you do alphanumeric down instead of across?

    The search direction of a list should be obvious. When it comes to a multicolumn list, you should always head down instead of across for legibility.

    Bad alignment
    Bad example: The list columns go across instead of down
    Good alignment
    Good example: The list is going down
  13. Column Data - Do you know when to use columns or text?

    It's OK to use text because it's more natural, but use columns if you need:

    • reordering
    • side by side comparison
    • totals.
    Bad alignment
    Figure: While text looks more friendly, in terms of presenting data it's not the easiest to read
  14. Do you make the homepage as a portal?

    You should put all the useful and current information on the homepage and also make it easy to find your core functions there.

    E.g. Top billing customers for the month and a button under it for adding an invoice.
    E.g. See the number of bugs counted by the most common.

    TWA
    Figure: The homepage of TWA is a portal.
    Adobe Illustrator
    Figure: Adobe's Creative Suite also opens a portal 'homepage'.
  15. Does your application's interface fit in a small screen resolution?

    One side effect of having busy forms is that it doesn't scale down.

    Each user prefers to have their own resolution. You must check if your controls will fit on the user's screen. Think about on which computers your application will run, and what devices will display it. To be on the safe side, it is advisable to fit your controls on an 1024 x 768px screen. Our projector has that resolution and it may well be used for presenting your application to the client.

    Bad Interface Design Example
    Figure: Bad Example - Form is too large to fit inside 1024x768px resolution
    Good Interface Design Example
    Figure : Good Example - Form fits inside any screen resolution

    The potential solutions for this problem are:

    1. Reorder and move the controls around on the form.
    2. Implement Tab pages.
    3. Use a wizard type interface, with Next, Back and Finish.
    4. Create multiple forms each containing a subset of the controls.
    5. Create a menu based form where the items are categories that some form controls fall under.
      Similar to VS. Net's Tools -> Options.
    6. Hide unimportant controls and add the option to show them if necessary

    Read our rule on Do you design your web pages to work on 1024x768px (not 800x600px)? to know more.

    We have a program called SSW Code Auditor to check for this rule.

  16. Authentication - Do you make the logged in state clear?

    Remember to make the "logged in" state clear enough to help the user know the current state.

    sample of logged in page
    Figure: Bad Example on Web form - The user is logged in, but it isn't very clear
    sample of logged in page
    Figure: Good Example on Web form - It's clear that the user is logged in
    sample of logged in form
    Figure: Bad Example on Win form - The user is logged in, but it isn't very clear
    sample of logged in form
    Figure: Good Example on Win form - It's clear that the user is logged in
    sample of logged off page
    Figure: Good Example on Web form - Logged off state
  17. Do you log usage?

    So you can see what functions are being used more often (e.g. reports, menu items)

    Plus, you can work out what fields to show on search pages (standard and advanced tabs) and which parameters are being used.

    Good Log usage
    Figure: Keep track of what terms are searched most often.

    You can acheive this with Redgate's Feature Usage Reporting.

  18. Give Context - Do you include extra information (e.g. Checkboxes)?

    Put in all information, even if some aren't selectable, provided there is context.

    This lets the users see what is available and what isn't, without being overbearing.

    Bad Example: The "Check broken links" checkbox in this case is not an option, but showing it gives the user context
  19. Give Context - Do you include extra information (e.g. Screenshots)?

    Good Example: The screenshot provides more, useful information and gives the user context
  20. Help - Do you have a wiki for each page or form?

    In agile development; updates, changes and bug fixes happen all the time and an issue that a user encounters today might already is fixed or have a workaround. That is why each page or form should link to a wiki page with any common problems that a user might encounter (and workarounds for them) and planned changes.

    This saves the end user from resorting to crawling the web for solutions.

    From: Tech Support
    Sent: Wednesday, 27 January 2010 4:31 PM
    To: Mr Northwind
    Subject: RE: Issue with lab management hosts

    Hi Mr Northwind

    There was a bug in Beta2 (fixed in upcoming RC release) wherein even if you have no lab artifacts in a host group, it did not allow you to delete host group from a Project collection in Team Foundation Admin Console UI until you delete the host groups explicitly from all the associated team projects.

    1. Run the following commands to project level association (make sure that there are no Lab environments in this Host Group).

      TFSLabConfig.exe DeleteTeamProjectHostGroup /Collection:<CollectionUrl> /teamProject:* /name:"Testing Host"

    2. Delete the host groups from Team Foundation Admin Console UI

      There was a similar issue with the Library shares also, and has been fixed now.

    Regards
    Tech Support


    From: Mr Northwind
    Sent: 27 January 2010 10:07
    To: Tech Support
    Subject: Issue with lab management hosts

    I accidentally (on scvmm) created a folder called "Testing" under by All Hosts group. In TFSAC I added the AllHosts\Testing host. This lead me to other problems so I tried to remove this host from TFS. Guess what? I can't remove any hosts from TFS at all! Even after I deleted it from SCVMM. The error I get is:

    TF259085: Team Foundation Server could not delete the environment location because the following All Hosts_Testing is currently in use: TeamProjectCollectionhostGroup. Delete the resources at this location, and then try the operation again. (type SoapException)

    I have no idea what this is telling me. Anyone have any ideas?

    Thanks!
    Mr Northwind

    Figure: Bad Example - The user encounters an issue and has to email someone about it
    Figure: Good Example - The 'Wiki...' link in the bottom left, takes the user to a wiki page with common issues and workarounds for this form (e.g. Creating a Project Portal)
  21. Help - Do you help users when they get errors by directing them to a wiki or KB?

    Every message box should contain a link to a wiki or KB with more details about the message. In the example of the below error message:

    No direct for this error
    Figure - Bad Example: User now has to google to find out how to fix this error
    Direct for this error
    Figure - Good Example: If you click on the "Get Help..." link on the bottom of the form it will take you to a wiki page with common issues and resolutions
  22. Do you strike-through completed items?

    Learn how to add "Strike-Through" to your toolbar.

    When you're giving an update on progress on a task list or a schedule, STRIKE OUT the items that have been completed. Not only does it visually explain where you are, it also gives you a great sense of satisfaction...

    Strike Through
    Figure: Good Example - Completed items are struck-through
    Strike Through in Outlook
    Figure: Good Example - Completed tasks are struck-through
  23. Do you use the Metro UI when applicable?

    Metro is Microsoft’s UI design guideline.

    Metro UI in TFSPreview
    Figure: Good example – TFSPreview.com adopts the Metro style
    Metro UI in TimePRO
    Figure: Good example – ssw.sswtimepro.com has been Metro influenced.
  24. Do you give the 6 social network options?

    If users want to make some information public, then make it easy for them.

    social networks links
    Figure: Good example – User can easily share information

Related Rules

Read the specific rules below:

Links

Acknowledgements

Adam Cogan


Benefit from our knowledge and experience!

SSW is the industry leader in Custom Software Development, Software Auditing & Developer Training.

Call us on +61 2 9953 3000 or email us for a free consultation

What does it cost? I’m not in Australia. Can you still help?