Graphic design without understanding the user, the flow and site interaction leads to pretty, uniquely identifiable web applications that are quite unusable and fail to connect with their users. Web applications that mimic the graphic design of others may seem to be more useable, because they are so familiar, but look like someone else’s product, have no identity, seem bland and boring, and also fail to connect with their users.
Somewhere there has to be a balance between familiarity, identity and usability, in a design that engages users. Here is how we found it.
This balance came to the fore of my mind as I am currently developing the latter stages of two, soon to be very popular, web applications.
I want them both to be
- Uniquely identifiable - where someone watching over a user’s shoulder can instantly recognize the application and pronounce its name. We don’t want to be mistaken for any other app.
- Intuitive - my audience for both applications needs to be able to see what they can do on each page, and have no fear in doing it. We don’t want them to miss out on the best benefits of the application.
- Familiar - the user needs to know what is clickable (like buttons and links), understand what each element means, and can understand the product without training. We don’t want to write a manual which no-one will read.
- Simple - the user should see only that which applies in the current context in the application’s workflow and not be distracted or confused by other feature’s clutter.
With these needs in mind, and with both applications quite functional, we presented the design challenge to two different designers, one for each app.
From one designer, we got back a unique identity. Great, this is what we wanted. It was also simple and uncluttered. Yes! But the design looked great until you tried to use it. You could not tell what was clickable and what was for show, and it did not use familiar idioms (its unique, remember).
The other designer went the opposite way. They presented us with a very simple design – good – that relied heavily on familiar idioms, also good. But a lot of our application’s unique features ‘disappeared’ in this design because they are not usually available on other sites and did not fit in. And the site looked like it was designed in the 1980’s and looked same as every other web site. No identity.
Testing the design
Before making any decisions, we decided to test these designs just to make sure our reactions to them were justified.
The best test of a static design is to show it to other people who are unfamiliar with the product and ask for their understanding of what was going on using very generic questions.
These did not work well:
- Do you like the design? Not a good question, most people will like any design. They feel bad criticizing other people’s work.
- How will you change it? Also not good, people intuitively know what works, but are often unable to say what needs to be done to make it better.
These worked better:
- What can you do on this page? Great, something practical, users started listing all the things they thought they could do, usually in the order of importance to them and when they saw the feature in the design. And when they stopped listing features, we also saw what they did not see. And were quite surprised.
- What do you want to do with this data? Also good, users intuitively know what they want to do with something they can see and feel, and will point it out. Also helps in priorities when simplifying.
In both cases, however, the people we asked liked the designs when shown it statically. Remember, these are people who have never used the application, nor understand is functionality.
Testing if it could be useable
We then demonstrated the alpha versions of both products to the same people. These are the versions of the software that were put together by developers, for testers, without design, graphic elements and style. We showed them what can be done in the application and asked them to ignore the look.
Then we went back to the design and asked them if it still worked in their minds. Now that our test subjects had a clear understanding of what the web application could do, they looked at the design with a fresh set of eyes. They saw the functions that were missing, they pointed out the unimportant things the designs made prominent and the things they would prefer to be front and center. And then they criticized the color, the placement, the hidden features, the odd idioms because they had a frame of reference to work from.
In the case of the identity design, they pointed out the usability issues, but still liked the overall design because it engaged them, and encouraged us to develop it further. In the other design, they also pointed out the usability issues, yet now hated the design because it did not engage them, and asked us to redo it. Engagement, it seems, came from seeing how the design promoted the most useful features of the application to our users.
Finding the balance
Since the first design had a great identity and was wonderfully simple, we went back to the designer on usability and familiarity changes. And we got them.
The other design, however, we wrote off. Instead, we sent it to a person who understands web usability and familiarity to start all over again. And their first draft was a much better start.
Great graphic design and a unique identity for your web application are great things, but not at the cost of usability and familiarity to the user base. A familiar graphic design makes the site more useable, but is not tuned to the features offered by the app, and actually hides them.
The best balance comes from simplifying the design to promote the things a user can do on a page, and to use color, typography, shapes and shading to create your identity around the useable components. By engaging the user in the application, by drawing them in with it’s easy to find and use feature set, and then by making it fresh looking yet intuitive and useable, that’s how you connect with your user. That’s how you make great web applications.