10 Guidelines for Making a User Interface People-Friendly

I am going to write on one of my big “pet peeves” this week.  The harshest criticism of most delivered software comes from people frustrated by their interaction with the user interface. In my experience, most change requests are related to users and the user interface (UI). Now I know that most project managers are neither the designer nor developer of the UI. However, during initial design and prototype reviews, there are best practices to follow based on human factors and cognitive science research that create a friendlier product. (I work on many projects with cognitive scientists and have been told this often!)

In September 2010, I talked about the user design from the perspective of flow and functionality in “Keep Users in Mind in Your Design.”  In this post, I am going to talk more about the presentation of information or action requests to the user rather than the navigation of the software. For the following 10 guidelines, I am relying on the insightful work of Jeff Johnson in his book, Designing with the Mind in Mind and the excellent book on documenting user requirements by Karen McGraw and Karan Harbison, User-Centered Requirements: The scenario-based engineering process.

  1. Consistency. People act first on their expectations and experience. To translate that knowledge to the UI means presenting options in the same way each time the user is required to take an action. For example, if the software requires the user to consent or affirm an action before moving forward, the consent window should always be in the same place, with the same options, using the same words, in the same order. It also means that if different pages have the same capability, for example “search”, then that option should always be shown in the same place on the screen.  At Cognitive Technologies (where I previously worked) we used the Performance DNA™ methodology to ensure a match with the user’s mental model and work processes.

Grouping. Take advantage of people’s natural tendency to group objects that relate to one another. Use spacing, font type and size and nearby controls to create a natural visual group that is clearly separate from other groups. For example, this page from Adobe Photoshop Help uses white space, color, font size and symbols to guide the user to selectable options.

And here is a SharePoint page that also uses white space, pictures, and grouping to guide the user.

  1. People read pages from left to right and top to bottom. Using this knowledge, presenting data in two columns, with the left hand column being the field name and the right hand column being the field value, is more intuitive to users than placing field names on top and values beneath them. I copied this example from Jeff’s book to summarize an individual’s mortgage:



$1,840.50            Monthly payment $662,611.22Total of 360 payments     Monthly payment     $1,840.50
$318,861.22Total interest paid September, 2037Pay-off date     Total of payments  $662,611.22
      Total interest paid  $318,861.22
      Pay-off date  September, 2037
  1. Breaking long lists into groups of three or four items makes them easier to read, remember and copy than a long list of numbers. For example a phone number shown as 2153345645 is more difficult for readers than 215.334.5645. Not to mention 16 digits credit card or 30 digit user license numbers.
  2. Use clean easy-to-read fonts. A contrasting background box can make text stand out; however do not use contrasting colors that cannot be seen by colorblind individuals, such as red on green.
  3. Avoid techno-jargon. Use LOGIN or SIGN IN as opposed to AUTHETICATE, for example.
  4. Do not place error messages too far from the point of data entry. People focus on a small 2 to 3 cm screen area when reading. An error message that appears at the bottom or top of the page may go unnoticed. If you must place the error message there, consider making it bright in color and blinking as our peripheral vision is effective at detecting movement.
  5. When presenting options, combining color differences with other cues makes it easier for users to automatically recognize groups and actions. For example, the Mac OS uses different symbols next to files in the process of being updated versus completed updates in addition to color differences. Your design goal is to take advantage of people’s normal brain organizing and visual detection capabilities to minimize the amount of cognitive processing required.

  1. Give users multiple ways to accomplish the same task. For example in a copy, cut or paste operation, people unfamiliar with the task may prefer a guided method using pull down menus or icons.  Others may prefer to right-click on highlighted text to bring up the editing menu. Another option is to highlight text and then drag and drop. And finally some people will choose the simple keyboard shortcut of: Highlight, CTRL+C (or X), move cursor to desired location, and CTRL+ V to paste. The important point for the user interface designers to remember is to give people options to accomplish a task that accommodates their tool knowledge.  Use good scenario based requirements gathering to create multiple ways to present information and tasks.
  2. Do not expect users to remember how they got to a step in a multistep action sequence. Show them a map or key and where they are in a process. As a matter of fact, it is good practice to give users feedback every time they take an action, because if the page looks the same after an action as before, the user may think they have failed and repeat the action.

So why do I write about making the user interface “people friendly”?  As a project manager, knowing a bit about the human factors behind effective user interface design will help when you review the UI for your project or to better understand user requirements and change requests. We are lucky at our firm because our project teams always include performance specialists who specialize in how people think, learn and work!  And that makes all the difference in the tools and solutions we configure and implement.

If you have additional gotchas or guidelines for user interfaces, please share.

Managing Implementation Projects – Tips and Tricks

Is there a difference in managing a project that is implementing a “Commercial-Off-the-Shelf” (COTS) application, versus managing a new software development project? Many of you would say there is a world of difference. In my opinion, it is not that simple – there are some project elements that are common to both, and some things that are much different.  Here are some best practices from my 20+ years of managing successful projects that I’d like to share with you today.

Software is Software
Technology projects involve that dreaded word “software.” But let’s not panic. First, software has become ubiquitous—with few exceptions, is probably inside of every physical item we buy or use today (cars, TVs, cell phones, etc).  Granted, not all software is the same. Some can be configured, while other software is “locked down.” When organizations
decide to build custom software applications rather than buying a COTS tool it is often because they need to lock down functionality to a specific use or process or because they need some special function that COTS software does not have.  More and more often, organizations are discovering that a COTS application will do 80% of what they need, with 30% of the cost.

Consequently, I have been managing a lot of Microsoft® Project and SharePoint® implementations this year. These software products are very powerful and can be highly tailored to an organization’s business processes without writing new software.  Projects to implement and configure tools such as these tend to ignore some of traditional software lifecycle aspects and I don’t think this is a good thing. Here are some of the steps I think still need to be included when planning and managing an implementation project for a COTS application.

  1. Requirements.  It is the key to successful projects—COTS or not.  Managing a project still requires knowing what the client and user requires and really needs (vs. wants) to produce their job outcomes.  (Listening to Customers)
  2. Planning.  I don’t think I have to elaborate for my tradition PM readers – this is the only way to identify and set expectations, schedule, staff and resources.
  3. Design.  Even though the application may be COTS, I find that the choices for configurations, the level of customization, and the ability of the latest generation of tools
    to change the look and feel of the product – really does require a good design.  Hopefully the design is done by professionals who are experienced in the software and have implemented it before. (Design with Users in mind)
  4. Testing.  I would hope that any project involving software would include this element, but have been amazed at how many times I see something put into production without testing because it is a COTS solution. Be sure your users get a chance to test the new application (UAT). (For more on testing see the post on usability testing.)
  5. Documentation. I can’t say enough about this – and I am NOT talking about the manufacturer’s manuals. Documentation does not have to be volumes of paper. However, there should be something for the support staff that documents the configurations and changes that were made to the system. I find that when outside consultants are used, this activity is more likely to be done. In my experience, when internal staff perform the configurations, documentation to more likely to be “lacking.”
  6. Training. My #1 pet peeve is that too many organizations are now “short changing” training to cut costs. They expect that all their users need is a simple, short one-hour overview and they will become experts in using the system. I fight to include a more robust and comprehensive training as a part of the projects I manage – and yes, I know that this increases the cost of the project.  But in the long run, training that equips people to use these new tools to do their jobs also increases the likelihood of system acceptance and long-term success!  (Making training better and How not to do training)

People are People
Back in 2009, I wrote a post titled “Does anyone listen to the Customer?” which was about how the PM should be the client advocate.  In practice, a project
manager uses customer requirements, resource knowledge and experience to construct a realistic project schedule and budget.  But a good PM knows that on a COTS implementation, the customer does not really know the full limitations or capabilities of the product.

I am currently managing a project where the Business Unit clients were being asked to tell what they needed the system to do.  This was without first giving them either an
expert to guide their input, or showing them what the application could potentially do.  These are people who know their business really well – but do not have a concept of what the new application might do.

Now I believe in focusing on solving business problems for a successful project, but the process for building good requirements should not lie completely with a novice business user.  We will either get requirements that cannot be accommodated or miss opportunities to really leverage the new tool because “they didn’t ask for that function or
capability”. If the user knew all of there was to know about the tool, he or she would probably not be in the business unit but rather in IT.

At the end of the project we want the implementation to actually solve or improve some real business process issues. The best way to insure that is to involve the people who have to use the technology and see what intersections can be made between the application’s functions and the user’s job outcomes.

So how many of your projects are actually “implementation projects” rather than software development ones?
Leave us a comment….

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts


Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another WordPress.com site