Yahoo have recently added a number of social patterns to their existing Pattern catalogue. The patterns focus on Ratings and Reviews and Reputation. The reputational patterns are particularly interesting as a lot of them give rationale, links to related articles or on going discussions on the web. I’d would recommend that anyone with interest in usability and social media take a look.

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!

It struck me the other day both how mobile devices are likely to drive improvements in the usability and accessibility of sites, especially those that want to give their users a similar experience on mobile browser and web browser.

Hiding functionality of information behind hover states and using a bit of dodgy javascript as a way to trigger them has always been a no-no but finding a way to convince clients who feel it makes a page more exciting is often difficult. With the advent of touch-screen mobile devices we can now side-step the discussion completely – no hover state whatsoever – joy!

Also anyone who has tried using their mobile browser to look at sites which pack in links and functionality without a thought for space, then found their Homer Simpson fingers have no chance of finding their target without opening adverts or clicking the wrong buttons, I’m in your club. Hopefully over time sites will start to add the necessary space and think about which buttons sit next to which.

From an accessibility point of view, I can see some of the features of screen readers would be useful in mobile browser pages, particularly information heavy ones. Pulling up a list of links or a list of headings would really help getting an overview of a page which requires a lof of scrolling. Also quick hand movements of key-strokes to trigger shortcuts would make a big difference. I’ll be keeping my eye on advances in mobile browsers to see if anything like that makes an appearance.

A few years ago, I was at a presentation by Don Norman at the NNGroup Usability week. During his presentation, Don said that “the product is more than the product”. It didn’t really hit home at the time quite how much extra product a product can really have until recently.

We use Ocado for our weekly shop and the user experience is fantastic, more than just online shopping or food delivery, everything is set up to make it as simple as possible for you.

Your shop is delivered in a specific, short time window. Contrast that to other delivery companies who give you a half day or worse still a day window.

The printed bill that the people doing the delivery give to you is organised into what you will do with your shipping next – cupboard, fridge, freezer. Better still the food is organised into bags in the same way and they are colour coded.

The bill also summarises where you have saved money all into one section. You could say this is good marketing for them but it’s also good in financially tight times to see how much you’ve saved.

Finally, they’ll pick up your bags from last week for recycling and give you a free paper. Genius!

All of those things are separate from the online shopping experience which is equally as pleasing and now available on the iPhone

Well done Ocado. Showing everyone how it should be done!

We recently added a twitter feed to our homepage. It was a good little user experience lesson and took a few iterations to get to something useful.

Here is a quick summary of the decisions we made:

• We wanted to show something current to attract interest back to the site, so we chose to just show the last 5 tweets only
• As we already have a blog and showing all tweets at once meant they were pushed below the fold, so we chose to use a carousel
• We chose to show each tweet in the carousel for 10 seconds. We had initially used 5 seconds but that didn’t give the user enough time to read and to follow a link in the tweet vanished
• As some users may have already read earlier tweets or just want to scan them, we gave them the ability to skip forward and back
• To get the maximum possible value we made all elements of the tweet clickable – links, users and soon we’ll add hash tags. We also made them open a new window rather than leave the site, so the user can open each link to read and stay on the site to open the next

They were our thoughts – what are yours?

Last night, with some time to kill in New Malden, the kids and I decided to pop in to a Korean supermarket. There’s a big Korean community in that part of London, and as well as delicious-smelling restaurants there are lots of minimarts that remind me of the Indian and Caribbean stores in South London I used to go to with my grandparents.

The staff were very friendly and regarded us with curiousity and amusement as did the exclusively Korean clientele, and it was only when browsing that I realised that all of the packaging and labels were in Korean (I know,I know). For a while it was really disorienting and we all ended up gravitating to things that we recognised – Korean pot noodle equivalents for my teenaged son, biscuits for my daughter, and packets of seaweed for me.

It made me realise how the visual components and behaviours that we take for granted when developing our applications could seem just as bewildering to users not familiar with them. It made me glad in turn that we have Mark and Lilamani’s usability expertise to hopefully reduce the sense of vertigo for our end users, and I made myself a promise that we would keep factoring in usability testing for all of our products before they see the light of day.

Anyway, I don’t want to labour the point. The kids and I ended up buying a couple of items, all of which were what we thought except my “savoury snack” Jolly Pong which ended up being a very tasty Korean version of Sugar Puffs. Looking at the picture on the packet (Korean writing over what look like Sugar Puffs) I don’t really have an excuse for my assumption other than it came in a savoury snack looking package What’s Korean for caveat emptor?

Finally, a plug for the shop itself. It was called kmart and they were very friendly and very reasonable, even before the 10% discount we got! We’ll definitely be back to stock up on the Jolly Pong and maybe some more exotic/healthy options.

The song needs no plug as far as I’m concerned, but for readers born this side of the 80s here is a live version on YouTube (sadly I couldn’t find a live performance).

I was looking through our blog the other day looking for an old post which had something in I wanted. I thought I would speed up finding the post by using the tag cloud and it struck me what a poor interface control they really are. I think that it comes down to a number of issues:

• context
• volume
• order
• underlying issues with tagging in general

Context

I don’t remember the last time I saw context information for a tag cloud beyond the page it was associated with. Typically you might find them on a blog or a page of case studies so you can guess that maybe these are all possible tags but it’s rare to see any kind of time information as a label e.g. Tags for last month’s articles

Relevance

To support the context point above, I also don’t always want all tags, I want ones that will help me find what I’m looking for and show me trends. I may have written a lot about West Ham at the start of the year but be too embarassed to talk about them now but my shame will be revealed by a cloud showing tags for the whole year. Perhaps it would be better to show two breakdowns, the last month or three months (obviously depending on what you’re tagging) and everything.

Order

There doesn’t seem to be an emerging convention across sites what order show tags in. Some show in the order you first used the tag, some show in alphabetical order, some show most used first. I think alphabetical order is probably the least useful as different people will use a different tag for the same thing – you say macbeth, I say the scottish play. Then first used and most used well again I think this depends on when/why you are displaying the tags.

Tags

Yep – I do think some problems just come with tagging’s baggage. It’s so easy for you to end up with a number of tags which are really should be the same e.g. socialmedia, socialnetworking (social media eskimos can argue amongst themselves that these are really different). It’s easy to end up with huge numbers of tags even with a small number of things to tag. I recently looked at a competitors case studies and there was a full web page of them – horrible

So, clearly if I’m writing this post, we couldn’t leave out pages using tag clouds. We’ve now switched to summary tables in usage order (clearly labelled of course) with a full list of tags should you need them. I’d be interested in whether anyone has ever done any usability testing with tag clouds and what they found.

This is a nice example of a paper prototyping session for a mobile interface.

This is a TEDtalks from 2006 which I only found over the weekend.

I found it really enjoyable and there are lots of useful learnings for user interface / application design. Barry talks about the implications of a growing number of choices (giving us freedom) and where responsibility for making those choices now sits. He goes on to talk about how the number of choices impacts your level of satisfaction level after having made a choice.

It definitely made me think about how you deliver choices to users in applications, how many to give on a given page both to maximise their ability to make a choice (avoiding the paralysis of having too many) and also their feeling of satisfaction after having made it. For me this means your application has to know a lot about the user and then use that to serve up a limit number of useful choices to support them in achieving their goal. Easy peasy!

Lets see what difference that makes to True North applications in future.

There are a lot of good user interface pattern libraries that are available now – UI Patterns, Welie etc. which covering both general and specific topics.

Although patterns are often categorised e.g. Search, Navigation one thing I haven’t ever seen, although maybe it exists, is a set of macro patterns.

I think there is a lot of value in having some coarse grained patterns that you apply to a specific scenario that as you consult with the client you remove/include elements of.

If we take the example of an Inbox. Inboxes are useful in any situation where you have a pool of resource to allocate work to. Depending on the way your pool of resource operates and is managed determines how you might apply the pattern.

The basics will be there:

• sortable columns
• sensible default sort
• filtering
• icon columns for space saving and clear communication
• highlights e.g. new or unread
  etc.
• actions
• selection approach

Then there will be some variable elements

• allocation statistics
• filtering
• rules
• pagination

and many more, all of which depend on your need.

We will be releasing a set of macro patterns, adding to them as we complete client projects. If you are interested in hearing more or speaking to us about them, please contact me

We’ve been working closely with two charities recently, so when I was reading through Jakob Nielsen’s alertbox archives and saw his article on Donation Usability it caught my eye.

The article describes the steps non-profit organisations should take in order maximise donations. In short it’s descriptions of two things:

• what the charity stands for (and in particular mission, goals and objectives)
• what your money is used for

People want to know what the charity stands for so they know it shares their ideals and values, then knowing that, how will they do it.

To get this right, the following things are important:

• answer the questions at a high-level on the home page
• have a clear IA to allow the user to find the underlying detail
• make the entry point to the donations process clear
• make the donations process simple (although this is usually a third-party service)

Another useful tidbit was that websites were more for small-scale impulsive giving but newsletters are better for long-term donor loyalty.

This was from the short report but there is a whopping 124-page report for the people who have got the simple stuff right already.

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.