I wanted to take some time to identify what I feel are important steps that everyone should go through when creating a user interface. I firmly believe that usability is all about common sense and that at the heart of a good interface is a set of simple rules that are easy for the user to learn and remember so they can move effortlessly through your application.

I am going to use this post to look at the early stages of the design process. My assumption is that you will have been through some steps to identify the user and business requirements and the tasks/processes the user will go through to achieve them, be that through interviews, contextual inquiry or testing an existing system. If you haven’t, don’t let that stop you, it never usually stops anyone else.

The end point of this part of the process will be a set of wireframes and a screenflow diagram. Wireframes form an ideal end-point as they can happily feed into graphic design or be expanded on a little to form a testable paper prototype.

Before we go any further, I just want to capture what these two artefacts are to me as I know there is varied opinion on what they should contain and look like, so:

• Screenflow diagram – for me this means identifying single screens or pages in an application, showing how they are connected to each other (how the user can navigate or action and move between them) and identifying the goal or goals of each one. I see a screenflow diagram as being different from a site map as a site map is just a representation of the page/information structure. However, both could be used to document application templates.

• Wireframes – these I would define as a representation of pages of an application. They should show layout, component structure and functionality (either by using a series of pages to show functional states or using notes as descriptions). They do not show brand or design information.

So where to start .. as a first step I would mind map out the processes, user requirements and business requirements that you have received or gathered yourself. This should start to show you where there is commonality. I would consider each “task” as a page to begin with and then rationalise and consolidate them as a second step. When consolidating think whether you are adding confusion to any process or simplifying, whether you are creating a natural hub or stop off point. Also consider breaking out pages for specialist functions.

Once you have your pages, transfer them over into blocks on a screenflow diagram and start to link the flows. You will probably need a few iterations to get this right. Finish by describing the user goal on each page, this will help you understand if there is any room for confusion i.e. goals are duplicated, in conflict or woolly.

Once you have finished with all the standard pages, consider the homepage. It should have become clear what the key messages you want to communicate to the user are, what the start points for them are, these can form the basis for your homepage.

You are now in a position to create wireframes. This is where you should be thinking patterns and principles. When I say patterns I mean coarse grained ones – form filling, registration, inboxes/results pages rather than auto-complete and other finer grained ones. Coarse-grained patterns tend to get you greater standardisation and act as a helpful checklist. I will cover some in a future blog post.

As you add elements to your pages start to document a set of principles/rules and consider whether the element fits in with an existing principle or rule of your application or whether you’re creating a new one. I usually document these in a presentation so that I can deliver them with the wireframes. You’ll be able to read over them later and make sure none are in conflict and also review your wireframes against them.

At True North, we have a set of web application shapes to help us create wireframes in Visio. It saves us a lot of time, especially when you are using standard patterns. You can download them and use them yourself. Just save the shapes file into you’re My Documents > My Shapes directory then when you create a new document select File – Shapes – My Shapes – True North Wireframes.

After switching the layout to landscape, I always create a standard background that I use on every page. I include the browser container, the notes container and the document information container and then make that tab a background tab.

I use the natural visio grid to help me position elements. It makes my eyes bleed to see things not aligning to the grid lines and I believe that if you do it too often your page starts to look messy and confused so avoid it if you can.

So at the end of this process you should now be in possession of a brand-spanking new set of wireframes, principles and a screenflow diagram to hold them all together. Now you’re ready to go out and test them with your users. Good luck!

We are currently working with a mobile telecoms platform provider to help customise their point of sale product for use by an Albanian mobile operator. It’s a complex project and has a large delivery team and as such good communication is a key factor in our success.

The team is approximately 30 people spread over London, Ukraine and India. The connectivity in some locations is poor, and couple that with no common first language, communication is often problematic using skype or the phone. The requirements documentation has posed their own challenges with document authors being unavailable having moved to a new project or sometimes left the company altogether.

In the early days, the result was that the team delivered a solution which was not what the customer wanted, not what the business analyst expected but which took a lot of hard work from developers leaving them somewhat demoralised. We realised pretty quickly that this wasn’t workable.

Our solution has been to use wireframes as our primary communication tool. They accurately capture the flow through the system, the expected input to the system and response to the user and are language agnostic. They have made a huge difference to how close to the customer’s intended outcome we are and everyone feels more empowered and enthusiastic as a result.

We’ve iterated a few times to reach an ideal set and to save you time I have listed them below:

• provide a high-level screenflow which shows navigation pathways through each screen in the wireframe set
• label each screen clearly, give it a title and author with contact details and make sure that is shown when they are printed
• publish them in a format which everyone can open (and which doesn’t get trapped by virus checkers) e.g. pdf instead of visio/html
• include annotations to explain functionality and show functionality over a series of pages in your wireframes e.g. an autocomplete before any text is types, offering options, selected option
• if there are subtleties e.g. alignment is deliberate, treatments are deliberate (for mandatories), make these explicit either in a separate set of UI guidelines or using annotations

I have also captured some comments from the developers and the client below, just to illustrate how it helps everyone.

In an earlier post, I talked about the importance of wireframes as a communication tool. As we’re working with Android, being able to quickly create wireframes for Android phones is a must. I’ve looked around for a good set of Android shapes for Visio and couldn’t find anything suitable, so I have created some that you can download.

The library includes:

• project layout, chrome and notes
• navigation controls
• feedback controls
• lists
• form elements
• gestures

I think this is a pretty complete set but please let me know if you feel it is missing anything that I should add.

To make it easier to see how to use them, I’ve also included an example set of wireframes (visio and pdf) that you can download. It shows an android version of our time recording application.