Archive for the ‘UX Guides’ Category
Telling Tales – Stories for promoting user experience.
Stories have long been an important way of recording and imparting information, as evident through the survival of folklore, myths and songs from our past. As a tool for communicating, and retaining information, they are highly valuable, and the principles of this can be applied to the promotion of User Experience.
Why do teams need to understand UX?
When working within a team, whether it’s a small web development company, or a large multi-national company, it’s impossible for one person to oversee every aspect of development. That is why it’s important for everyone to understand the principles of user experience, due to the large variety, and span of tasks that it encompasses. A good user experience designer is not the one who works longer hours, or has more creative control over the final product, instead they are the one who makes sure everyone understands UX goals, and works towards them.
It is this reason that books such as Krug’s Rocket Surgery Made Easy heavily promote the idea of getting everyone, from the CEO to a junior developer, involved when testing with real user’s, as it is these people who will be able to implement user experience ‘fixes’. The solution Krug suggests involves inviting these people to view the user testing sessions, and bribing them with snacks.
Because encouraging successful user experiences requires everyone’s involvement, it’s important that everyone understands the goals of user experience, and can incorporate them into their work. The problem is making them understand what those goals are.
Pictured: not a goal
What are stories good for?
Homer’s Odyssey was composed in the 8th century BC, and yet a canonical written version wasn’t produced for another 300 years. Before this, the tale was remembered, and shared orally, through song. Considering that the Odyssey contains over 12,000 lines, this is no small feat. That’d be like remembering, and reciting on demand, every blog post I’ve done so far… So how was it possible?
The answer lies in the power of stories. Stories, like Homer’s Odyssey, are memorable, due to the plot and the events contained within, and hence easily form visual images within the mind, and aid memory. Plots make stories interesting, and hence easier to remember than non-fictional texts (such as remembering all of my blog posts).
Stories can also be used to impart useful information. These be obvious life lessons (The Three Little Pigs teaching the benefit of putting adequate effort into your tasks), or life saving, such as Ring a Ring o’ Roses imparting symptoms of the Black Death (although this may not be true)
or Cinderella teaching us the dangers of stepmothers
Using stories for UX
So, stories are memorable, can be used to impart useful information, and are easily transferred, as made evident by the 300 years that Homer’s Odyssey lasted without being written down. Hence they seem ideal for the promotion of UX within teams, as they can be used to quickly impart the benefits of UX, and what each individual needs to do to aid a user centred design process, in a memorable and transferable fashion. By bringing the whole team onboard with the principles and goals of UX, a greater degree of coherence can be achieved across the team. Therefore to get better results without manually verifying everything the team does, a User Experience Designer needs to champion user experience principles with all members of the team, and stories are an easy way to do this.
Some examples of UX stories
Many authors have understood how stories help to impart information in a memorable fashion.
- In The Design of Every Day Things, Don Norman uses stories of real world examples to emphasise the dangers of ignoring user centred design, with examples including nuclear accidents and plane crashes.
- Stories based on metaphors are also used by Alan Cooper in The Inmates Are Running the Asylum to emphasise the importance of designing for the end user, by comparing the software design process to film making.
Also of interest, Sam Nixon shared a short story by David Travis called “The Fable of User Centered Design”, which aims to bring clients and team members on board with the benefits of a user centred design approach. Definitely worth the read, and should be shared. The book is available to download from his website.
If anyone has other examples of stories that help define the importance of user experience, remember to leave a comment below!
Quantifying the unquantifiable – Expert Evaluations
At a recent UXBrighton talk, iCrossing presented an interesting idea about applying metrics to expert evaluation. This is a potentially controversial topic, yet has numerous benefits if it can successfully make qualitative data quantitative (and turn impressions and thoughts into numbers). I’ve outlined the method, and my thoughts on the issues around this.
The UXBrighton event was presented in a new format as a series of short talks, from Harry Brignull’s tips on time stamping notes, to Danny Hope’s templates for understanding user roles. Also interesting was a talk on using google analytics, although the length of the talk meant that topic could only be skimmed, dissapointing as I’m an analytics fan. The most interesting idea presented was iCrossing’s presentation on “The iCrossing Connected Brand index: how to measure a brand’s effectiveness online”, given by Ifraz Mughal.
Expert Evaluation
As I’ve mentioned before an expert evaluation is a useful tool for getting an insight into potential usability and user experience issues on a website, or game, with limited resources. Although it can never replace running tests with real users, it can provide a quick approximation, and help highlight the biggest issues.
The ‘method’ for an expert evaluation is simple. Get an expert to look at the site, or game, and tell the client what they think. Job done.
My expert eye tells me you need smarter users
However an expert evaluation can only ever be subjective, and this is it’s biggest weakness. A client can look at your page full of recommendations, and dismiss it as the opinion of one person. There’s no easy way to see progress with changes, and a comparison with other sites can only ever be abstract.
Quantifying an Expert Evaluation
iCrossing’s solution is to quantify their expert evaluation. As part of their ‘Connected Brand Index’ idea, they rate their clients sites (and competitors), on UX-centric areas such as “usefulness”, “usability” and “desirability”.
A traditional expert evaluation would give a qualitative rating, and give examples to back this up, i.e. “Poor – little emphasis, and diffused call to actions”. Instead iCrossing will give the site a score, on a scale of -2 to 2 (2 being very good). This of course can be backed up with examples in a more in depth report.
after the first few pages, the report can just be pictures of kittens. No-one reads that far.
The advantages:
There are numerous reasons why a client would prefer a scored ‘rating’, rather than comments.
- A ‘score’ makes it easy to benchmark, and compare your own scores against competitors. By dividing the expert evaluation into separate topics, and scoring each, a finely grained comparison can be made, and communicated
- Similarly, a score makes it easy for a client to see progress. If they scored -1 before hiring you, and 1 after, your work can be justified (as long as no-one questions who is doing the scoring!)
- Because this produces a concrete score, clients will be able to handle and communicate the data. Graphs can be made, which wouldn’t be possible for subjective comments. These can be invaluable for justifying and communicating with managers and project sponsors, who do not need to see the details, just get a high-level overview.
- This expert evaluation can be encompassed as one aspect of a larger ‘score’ given to websites, or games. This is the idea behind iCrossing’s connected brands index.
Conclusions:
There is an argument this can be seen as a bit of a scam. Giving arbitrary numbers to your opinions doesn’t make them any less subjective. This method of presenting the data could be misleading if presented incorrectly, and the client should be made aware of the method behind the score system. This could become an issue when running comparative studies before and after your work, since you’d be biased towards giving the site a better score after you’ve worked on it.
The point of this method is to aid communication with the client, and give them data in a format that is useful to them. As I discussed in the review of Selling Usability, management and non-technical people would typically much rather see pretty graphs, and statistics, than a list of comments. This method helps manage client expectations, and gives them what they want.
To make the method more valid, it would be useful to perform a study to ensure the method is sound. Perhaps get a wide range of experts to independently rate a wide range of websites on this scale, and note the correlations between the scores. It’d be first step in countering complaints that this method is still inherently subjective, and help make an art into a science.
The Uncanny Valley of Wireframes
The uncanny valley is a theory describing how, as games and robotics produce more accurate representations of humanity, people’s reactions towards them are increasingly negative. This is also true with the production of wireframes, and in user experience testing and is something user centred designers need to be aware of.
The uncanny valley was originally discovered in the field of robotics, but also frequently applies to video games. It describes a phenomenon with replications of humans, whether they are life-like androids or avatars on a computer game. Initially, as the reproduction of a human and its movement becomes more lifelike we react more positively towards the object, so we’d like Lara Croft more than Leisure Suit Larry. However a point is reached, when the reproduction becomes too life-like, and the emotional response drops rapidly, meaning we feel repulsed from the object. Consider Keanu Reeves’ acting. Almost human, but utterly repulsive!
The term ‘uncanny valley’ therefore comes from plotting a graph showing our emotional response against how lifelike the reproduction is, with a sharp ‘valley’ appearing in the emotional response between a very lifelike reproduction, and the real thing.
Got that?
A similar phenomena can be seen in the production of wireframes, and hence is of critical importance to UX designers. After spending hours producing beautiful wireframes in Omnigraffle, I presented them to a client, to show how their ‘event registration’ pages would function. They came back and said “yeah it looks good, but we need to change that label text… and we need to make the dropdown arrow bolder… and can we make the heading font bigger”. This was their first view of the wireframes, to approve whether they functioned correctly, and it’s obvious what I’d done wrong.
The time and effort I’d put into making the wireframes look good, and look like a real website weren’t just wasted, they were actually hindering the process – since the mock up looked like a real webpage, the client was focusing on the small presentational details, and not the functionality itself. They expected it to look and function like the final product. If instead, I’d done a rough sketch on paper to demonstrate how the registration process should work, the client would have focused on the functionality instead. A design that looks to be in the early stages will encourage more far-reaching comments and criticism, rather than ‘fine-tuning’.
This is most important when you’re trying to focus the user experience when performing tests, especially with people not overly familiar with your site or game. Performing tests to ascertain the correct information architecture, or user’s experiences with a website’s functionality would be useless if all your comments ended up being about the site’s colour scheme. To make it clear that the designs are rough, and the presentation is not the focus, it is important not to create overly realistic designs.
Similarly care should be taken to pick an appropriate prototyping method. Paper isn’t used just because it’s quick and easy, but it also helps manage the client’s expectations. If you spent the time making the webpage on a computer, they’d be expecting it to work like a real product. On paper, this isn’t the case. Like the uncanny valley, getting too close to the real thing will be detrimental to the client’s perception of your work.
And you wouldn't want your work to look like this...
So, what steps do we need to take to ensure that the client, or user will focus on the right areas of your wireframes and designs?
- When performing initial designs, use lo-fi methods, like paper, post-stick notes, and whiteboards, where possible
- If using design software, like Pidoco or Omnigraffle, use a ‘sketches’ template, which renders your design in a pseudo-drawn method.
- Avoid drawing/designing unnecessary parts of the design – focus only on the essential
- Use filler text, and don’t work on the copy until later.
- Make it clear to the user/client that these are rough, disposable prototypes.
So, whether you’re working with a client to design their site, or conducting user testing, take care not to over-present the design, in order to manage expectations, and prevent unnecessary complaints!
The Likert scale – Or “How I learnt to stop worrying, and ‘strongly enjoy’ the bomb”.
As a practitioner of usability or user experience, a common way that you will attempt to investigate a user (or player, or customer)’s perceptions is through designing and implementing a survey. In designing a survey, its important to consider the format that questions come in, especially with common question types such as “How frustrating did you find this level?.” Today we’ll look at one of the most common question formats, the Likert scale, and the implications that using it has on your studies.
What is the Likert scale?
Lets start with an example.
Most people have seen a Likert scale before. Do you agree with this statement?
- Strongly agree
- Agree
- Neither agree or disagree
- Disagree
- Strongly disagree
And the responses should be balanced... unless you have an agenda
Often used to gauge opinions, they are especially important for people involved with measuring usability or player experience, as they can help quantify subjective things like a user’s experiences. They are usually in the form of a statement, followed by a selection of statements, to indicate how far someone agrees with the statement. They can often be used to quantify things like ease-of-use, or fun, which would be impossible to quantify through other methods. Hence they are of particularly important for us, since user experience is essentially abstract.
Different kinds of Likert scales.
The essential question when it comes to implementing a Likert scale, is how many responses to offer.
‘Forced Choice’ scales are those which have an even number of options. Essentially this means missing out the ‘neither agree or disagree’ option, and forcing the participant to make a selection (see what they did with the name? very clever!). This would be done to force participants to show an opinion, but there are dangers inherent with this. Forcing a response may give a larger degree of ‘static’ in the responses, reducing their accuracy, since the responses may not map their opinions. People who don’t agree or disagree may not be happy about being forced to give an opinion, reducing their likelihood to answer later questions accurately. However if your aim is to support a conclusion that people do/do-not like a system, you may be willing to risk these to prove your point when designing the survey.
Forced choice means its hard to tell who is neutral, and who doesn’t want to participate
If you select to use a scale with an odd number of options, there are a few issues that should be kept in mind when deciding between a five or seven point scale. The most obvious difference is that a finer grain of responses can be analysed from a seven point scale, as it can represent a wider range of views. Also, take into account that it’s been shown participants shy away from the ‘edges’, the extreme like and dislike options offered. This means a five point scale will likely only get responses in the ‘slightly’ columns from all except the most ardent fanatics. Again, you have to consider whether a wider range of responses is useful to the topic you are exploring.
Should you use a Likert Scale
Ultimately if you are trying to track opinions, a Likert scale is a good method of accessing this data. There is no all-encompassing correct answer for which scale is appropriate, the context of use and what you want to find out will all affect this. As long as you keep in mind that not only the phrasing of the question, but the range and number of responses you offer will affect the results, and anticipate this affect, you can’t really go wrong. Happy surveying!
How to make an effective usability persona
Personae (or personas if you prefer) are an important part of a user centered design process, and one of the key ways in which usability experts can communicate their findings. I’m going to look at how to make a persona, and what the advantages are to you, and the design team
How to make a Persona
We’re going to assume you’ve already take some steps towards understanding the users. You could have designed a survey, or performed one on one interviews, and now you have a pretty good understanding of who your users are, and what they think about your product.
First we need to divide the people into demographics. Did all the women over 50 find your game idea too violent? Did most of the children think it sounded like it would get dull? Try to focus on the key areas where people picked up on things, and ignore the outliers for now – you want to turn all your results into 3-5 personae, of which only one or two will be the ‘key’ users you are designing for.
Now you want to write about these groups you’ve divided the people into. Make them real people; give them names, occupations and a back story. Make their name an in-joke, that’ll make you laugh, but no-one else will ever get (Hello Bibi Andersson). Include some text about how they’d use the product, and what they’d expect from it. Also include some concerns that they may have. You want these people to be treated as real people, and so they need to be complete! Include a picture, so that people can see the people they are designing for.
pictures make everything more fun
Why you should be making personae
There are many advantages to making usability and user experience personae. As a usability expert, it can help you by:
- Communicating your findings in a way that will be read (unlike that big 50 page report)
- Can be stuck on the wall, keeping your role in the team prominent
- Allowing you to make a definitive impact on the design of the product
- Incorporating usability and user experience principles from the start of the design process, promoting the use of your field as a holistic practice, rather than a ‘last stage’ of product development.
not that sort of persona
Why they need you to make personae
You obviously don’t just make personae for your own benefit. The design team benefits in many ways from your deliverable as well. Not only does it give them an easy way to understand your findings, and focuses on the aspects that are important in their roles, but it gives them a concrete person, or group of people, to design for.
A persona gives an important baseline for future developments by the design team. By understanding who they are designing for, it reduces coder’s natural urge to spend too long designing for the ‘edge case’ users, and focuses their attention on the core functionality required (perhaps an example of how to maximise with the 80/20 rule ). This reduces feature creep, as the team can consider whether the personae identified would actually use the new suggested features, and as such helps deliver games and projects on time, and to budget. I’m guessing that 3D realms did not use personae.
