Designing a Usability Blueprint for a New Admin Console

Posted by

An example of a detailed wireframe in early UI development
An example of a detailed second-iteration wireframe, after having tested the basics in a usability blueprint

Imagine that you've come up with a conceptual model for a new application, and want to get started with visual prototyping. What should the first wireframes look like? How do we decide the basics of what goes where, and how do we test these results? Let's look at one example: A method that we used when creating a new user interface for the Admin Console.

Starting by Using Conventions

One quick way of starting out drawing our first visual prototype, is to make use of established conventions in existing user interfaces. The evolution of graphic user interfaces has had a lot of time to develop, and although there are trends that come and go, many elements tend to be positioned in the same spot consistently across different interfaces.

There are quite a number of UI conventions that exist, here are just a few common ones:

  • Main menu at the top
  • Sub menu to the left
  • An aside with more info, or palette with tools to the right
  • Logo and bread crumbs in the top left corner
  • Toolbar somewhere up top
  • Action buttons in a corner at the bottom (left or right depending on software platform)
  • Search field in the top right

Of course, there is nothing that limits us from breaking the rules and trying something different – a main menu can just as easily be placed to the left and a search field can be placed in the top left corner. You'll see that such deviations are common in user interface design, and this is often a result of findings during user testing. The important part for now is to create a visual prototype that we can then show and test on our users.

From here, the path to testable prototype can be pretty straight forward, and we'll often end up with a UI looking very similar to many applications out there. No wonder, really, since we've been taking concepts that work in current interfaces, and positioning them where they usually are found. The advantage of starting with conventions is that you're creating a UI that many users are familiar with, and user testing can then reveal what parts that don't fit together in their current position.

Starting by Combining Theory and User Testing

Another place to begin, is by studying our users and base our design on where they expect to find different elements. However, very few people are able to imagine and describe a new user interface, unless they either have experience with UI design, or they are describing another application. If you want to examine their mental model of your concept, you need to show them something first. One way to create this first prototype, is by starting out with a model that is based on existing theories.

Eye Accessing Cues

Within the field of cognitive studies, it is a common notion that we percieve items in our world along axes of movement. For instance, A theory called Eye Accessing Cues (EAC) provides a theoretical backdrop for coming up with such axes in UI design.

Studies of EAC have shown that we move our eyes briefly in certain directions when we think certain thoughts. If there is such a basic connection between thought and ete movement, it may help to position interface elements so they correspond to these eye movements. For instance, when imagining somehting visually, most of us look briefly up to the right. Coincidentally, that's where the search field tends to end up in web design. It's hard to say if this search field placement can be linked to EAC, but it is intriguing, nonetheless.

A brief summary of various Eye Accessing Cues, vertical axis:

  • Sight-related thoughts are up
  • Hearing/story-related thoughts are directly to the sides
  • Feeling/decision-related thoughts are down.

Eye Accessing Cues, horizontal axis:

  • For about 90% of us, we move our eyes left for past thoughts and right for future thoughts. Note that this is data from western culture (left-to-right reading direction).

1. Using the findings above, we can create a group of mental categories which form axes that can aid us in drawing our first visual prototype:

Eye Accessing Cues

2. With these basic axes in place, we can start laying out various elements in our user interface, in a position where their basic function matches the basic thought category. Some adjustments to the axes may be necessary, but still trying to stay true to the idea:

Eye Accessing Cues with basic layout components

3. Finally, we now begin placing the elements that we have planned for our user interface:

Basic UI Blueprint

4. Now we have a blueprint that we can show and test on our users!

Testing the Blueprint

One way of testing our design, is by figuring out if our basic layout matches the ideas that users have of where they expect to find different elements in a user interface. We can do this by removing the labels into a separate list, shuffle them, and then let our users try to fill in the blanks, literally. Compare our blueprint above with the questionnaire with the labels removed:


The test is a quantative study, so it needs to be done on a great number of users in order to be trustworthy. In this case, it was done on 30 users, which is not a lot. Yet, some patterns began to emerge:

Easily positioned by users:
  • Main menu
  • Sub menu
  • Logo
  • Search field
Either/or situations:
  • Toolbar (top or bottom)
  • Action buttons (default action floated left or right)
Not understood by users (completely arbitrary pattern in answers):
  • Modal dialogs (perhaps because their presence is temporary)
  • Recent items
  • Search result

Final thought

Apparently, the elements that were easily positioned were also the ones that were placed in their conventional spot. It was not possible to determine if using a method based on EAC had any effect at all. This proves that you cannot simply follow a theory and expect users to automatically understand the system. No matter how much planning that goes into a design, it is through user testing that the real work should be done. Still, it is nice to know that we can use conventions and basic theories as a way to begin from scratch, before the product is user tested and further iterations are done.