Personae as a business intelligence tool

Personae are a potent business intelligence tool that are frequently misunderstood, misconstructed or assumptive. The consequences of rolling out "made up" personae as fact will ensure that any user experience is based around a premise.

Perhaps it's best to start out by defining what a persona is not. The idea that a persona is created by looking at a demographic segment and giving it a lick of personality veneer arouses dismay within any self-respecting UX practitioner.

I've seen many a personae constructed subjectively, outside of UX; hurriedly put together within pitch documents to demonstrate an awareness of a particular organisation's users. Having won the pitch, these personae are not interrogated, but believed by client and agency to be correct. They then get handed to IAs who use them to create user journeys.

Another mistake is for an organisation to predefine who they think their personae are and how many there are. This can only result in forced and diluted stereotypes that serve as a kind of pale doppelgänger. Or worse, too many personae, many of which are shades of each other. And from a business point of view, this becomes an expensive exercise that only distracts and confuses. Most persona investigation exercises yield around a handful of primaries, the median being around three.

The interesting thing about personae is that you never know what will emerge from your quantitative and qualitative data. There is something almost magical in the way archetypes emerge from the clusters of attitudes and behaviours of groups of people that you interview.

It is vital that your personae are empirical if you are to develop an insight into designing truly user-centred interfaces. I use a mixture of primary and secondary research, because it's important to validate what you discover through focus groups or interviews against data captured from surveys and the like.

Keeping an Open Mind

Remaining receptive means that you won't influence your subjects, who are often vulnerable to giving what they believe to be the right answer - after all, you are paying them to participate, and people do like to please!

This predisposition is often seen in user testing, where participants will give glowing reports of their experience on an interface, despite observational evidence to the contrary.

Setting the Criteria

It's important to establish beforehand, however, what you are hoping to achieve from your research. Are you trying to capture attitudinal data, are you investigating the type of content they would like to receive? There is a delicate balance between allowing people to wander off into delicious tangents, and bringing them back to the core of what you are trying to investigate. Allowing people to "flow" can often allow for deeper insights that may not have been uncovered within a rigid facilitation framework.

Another thing to watch out for is the group dynamic within focus groups. Some people like to lead, whilst others are passive. Ensure that everyone gets an opportunity to contribute.

It's a good idea to work in a small team when conducting primary research, so that you have several sets of eyes and ears, and can bounce your observations off of each other.

Identifying the Persona

After several focus groups or interviews, patterns begin to emerge. You notice that people across groups begin to show similar attitudes or needs. Your persona becomes a composite sketch of these findings. While your persona itself is not "real", it has its basis in real people...

Once you have what you believe are the full set of personae, it's time to discover who your primary personae are. These are the personae that, if you design for them alone, would in some way disenfranchise another persona. Analysis will reveal who the primary personae, with their distinct needs, are.

Your secondary personae will sit beneath, or between your primaries. These are the people whose needs are satisfied by designing for the primaries, but who also have additional, sometimes less important [from the business perspective], needs that can be easily accommodated within the design.

You may find that you have other personae who, while interesting, are not necessarily part of the main audience as defined by the business goals. For example, these might be people who wouldn't use a digital artefact for one reason or another. They help to form the wider picture, and these are your third, or tertiary personae.

Once you have created your hierarchy, you are ready to use your primary personae to inform the design process.

They become the voice of the user - a reminder to let go of personal whims or cognitive biases and design authentic user-centred products.

As a business tool, personae can be used across disciplines to enlighten and inform production. The insight that they provide means that a brand is communicating directly with people and not "consumers". It's never a good idea to have a static view on personae - each new project requires new research. If the business proposition changes or grows, new research must be conducted. A new game, a new hand of cards, so to speak.

Since personae are constructed from real people, it's useful to recall focus group participants or interviewees to test and validate as the product is developed.

The fruit of a tree is only as sweet as the strength of its roots; it's a grave mistake to be glib about what real people do and need.

And finding out what real people's goals are is simple. Just ask the right questions and observe how they carry out their tasks.

Interview with Robin Christopherson, Head of Accessibility Services, AbilityNet (Part II)

Part II : Best Practice IA, Technologies

Lynda : What are the common architectural blunders we make in terms of creating accessibility obstacles on websites?

Robin : The best practice in general page layout and presentation and that sort of thing that is quite well documented by people like Jakob Nielson’s work in usability – he’s quite a controversial character, but a lot of what he says makes a lot of sense – and also in the WCAG (Web Content Accessibility) Guidelines.

Basically, you need to have very consistent layout; you need to as much as possible conform with the recognised ways of doing things, the recognised behaviour of how websites work and are laid out.

But also on a page layout basis, have good use of white space. Separate your page objects, page elements by a few more pixels of white space than you might otherwise do. There’s always the temptation to cram as much above the fold as possible.

And then, from a semantic point of view, there’s a whole raft of things that you need to do so that content, functionality will be presented in a logical order for screen reader users like myself and people that use a range of assistive technologies that interpret the page in a different way than how it’s visually presented on the screen.

So there’s lots that you can do for, particularly, cognitive impairment, dyslexia and vision impaired groups smack in the middle of usability/UX. Far more in that camp than what people might think of in terms of accessibility.

Lynda : You mentioned in your presentation one column layouts – did you mean that it’s better to have one’s text sitting in a single column as opposed to the print paradigm of two or more columns?

Robin : Not necessarily. By all means, have two columns, or even three. It all comes down to how that behaves when people try, for example, to view it on a narrow screen or a small screen as in the case of a mobile device or someone who’s a magnification user, they might, for example, have their magnification set to four times, in which case they can only see a quarter of the width of the screen. They might typically reduce the width of their browser to a quarter of the screen, because if they don’t do that, then there’s going to be a lot of difficulty in always moving the focus down to the horizontal scrollbar, to scroll along a bit, go back up and look at the next bit of the quarter piece of text that they’re reading, and then go back down and scroll across again.

It’s vital that if text is zoomed up, or if people reduce the width of the browser, that the layout presentation that you’ve chosen doesn’t fall to pieces, or insist that you have it at 1024, for example.

It’s all about testing, really. And if, at the end of the day, you want to recommend that people ignore styles to give the best linearised layout for that group of people, then fine. But do make sure that the reading order is logical and you may perhaps want to offer them a style-free version, as a link using JavaScript, for example, where they don’t have to go and turn it off in the browser themselves. Just have a single column layout, you might call it.

Lynda : JavaScript’s quite controversial as well. Developers use JavaScript for a whole range of things from dropdown menus through to carousels, and very often can be inaccessible.

Robin : We’ve done a lot of work with the BBC to make sure that the widgets on their home page, the carousels on their iPlayer, EPG page, the panes that open and close in the weather page, for example, not only work for screen reader and keyboard users, but that reading order, for example when you open and close dynamic content using JavaScript or Ajax, the reading focus of the screen reader can often end up in a completely different place. So you have to do some really quite sophisticated things.

We would recommend people go and have a look at the source code on those different pages, the BBC home page, the weather results page, the Electronic Programme Guide carousel in the iPlayer area of the BBC.

As mentioned before, there’s been a lot of work done on accessible uses of JavaScript. We’re pragmatists. We don’t say don’t use JavaScript because JavaScript’s evil. There are loads of instances and examples where JavaScript can enhance usability no end, and also still be accessible. And in some cases, enhance accessibility, too. For example, by routing the reading focus of a screen reader to a particular place.

So JavaScript isn’t a bad thing by any means, but it’s probably easier to code inaccessibility into a page if you’re using a lot of JavaScript than if you were just using HTML.

Lynda : What about Flash?

Robin : Again, there are a lot of instances where people will ignore Flash plugins just because they’ve been burnt too many times in the past and they don’t want to spend time finding out that yes, this Flash is also inaccessible.

It’s a bit like PDFs in that case. They won’t even bother to open the PDF because they know from past experience that 19 times out of 20, the PDF hasn't been tagged at all. They don’t even bother opening it. So that people who have spent a lot of time and effort making their PDFs or their Flash accessible, they probably need to signpost the fact that they do tag their PDFs.

With Flash, again, we spent a lot of time and effort making sure that the iPlayer is accessible for all the categories of impairments, not just screen reader users, and it is a challenge, but there is very good documentation out there on the Adobe website, to make sure you know what you’re doing.

Certainly we wouldn’t advocate using Flash as a whole site or using it as main navigation. The old website for Ushida Findlay Architects was a good example of how not to use Flash. Their main navigation was a circle with little tiny dots and when you clicked on one of those, you got a bigger circle of smaller dots rotating around the edge as sub-navigation, so you had clicking on moving targets and Flash and keyboard inaccessibility and it was a real nightmare.

You can use Flash and it can deliver really good functionality, but you can also make it really difficult.

Lynda : Do you think as a workaround for PDFs that what we can do is also offer an HTML version of the PDF?

Robin : I think a lot of people would prefer to work with the HTML version anyway, because you’re still within your browser environment, you’re not having to open a new application, you’re very familiar with all the keystrokes of getting around HTML, for example, as a screen reader user like myself. But there are some instances where you might want the portability of the PDF or you might want to encapsulate a signature or something, if it’s an official form, so there are a number of instances where you’d need to have the PDF.

For people that have a lot of PDFs and there’s a real legacy issue there, then there is a decision to be made. Do you tag all the PDFs or do you offer RTF (rich text format) or HTML alternatives, and AbilityNet, for example, offers all of those services, because we recognise that tagging a PDF isn’t always the obvious first choice.

Part III : Demonstrating Accessibility Issues, Testing Tools, Audits, Benefits

Interview with Robin Christopherson, Head of Accessibility Services, AbilityNet (Part III)

Part III : Demonstrating Accessibility Issues, Testing Tools, Audits, Benefits, setting up an accessibility infrastructure

Lynda : A lot of websites provide only minimal accessibility measures, such as font increase tools, access keys or text only versions. Perhaps this is because they are genuinely unaware of the problems disabled users face when interacting with websites. It could be that part of the problem is that they are unable to replicate the experience and therefore don’t grasp the importance of accessibility.

If I were to demonstrate a typical disabled user’s experience of a website to the website owners, what would be the best way of doing so? (I understand that the term “disabled users” includes a vast array of disabilities and levels of abilities, so perhaps a broad overview would be better.)

Robin : There’s a number of things that you would do. Immediately change the text size and see if everything scales up. If it doesn’t, that’s obviously a no-no. If it does, but things get cropped or overlap, then it’s very visually striking and you can show quite quickly how the page is not catering for the broadest group.

Tabbing through the page with the keyboard, and seeing if you can follow the highlight, see if it’s a logical tabbing order, all those sorts of things.

But then you need to move onto things like viewing it in a smaller screen, or turning off JavaScript and seeing what happens. Try running a screen reader like NVDA (Non Visual Desktop Access) – it’s a free, open source screen reader. It’s a very fast growing screen reader sponsored by Microsoft and Yahoo and Google and people like that. That’s going to be a really useful tool going forward.

A lot of the time people see JAWS (Job Access With Speech) - which is the global default screen reader - as very expensive, too complex to use as a testing tool, etc.

Just going back to the comment about offering text only alternatives, about ten years ago, if you didn’t have a text only alternative offered, then you weren’t “catering for disability”, and where the disabled community never really wanted to have a sort of ghetto situation where they were just being offered, in many cases, a much more reduced content and functionality to the parent site. Things have come full circle now, and if you‘ve got a text only link on your website, then it’s kind of like an admission that you’ve messed up the accessibility on your main site and you’re having to offer a bolt-on alternative.

So text only is out and what we are using now is one site which can be served up in many yet ways, using style sheets, using, for example, the screen reader flag in Flash to detect that a screen reader is present and serve up the content in a different way.

We’re not advocating an alternative mobile version unless your source code is so bloated and you’ve got a legacy that you’re having to deal with the source code of each page is 1MB per page, in which case that would be a disaster for people to have to download - albeit then served up using a mobile style sheet in a really nice way for mobile screens to access. But they have to nevertheless download the whole source code before the style sheet was applied. If they’re on a pay-as-you-go data tariff, then they’re going to be paying an awful lot of money to download 1MB of data on each page.

There are caveats that the main principle is that you’ve got one site that’s designed to best practice to be as inclusive as possible and then you offer different style sheets to serve it up for different groups. You also make decisions about what additional functionality you include to go that extra mile for certain groups.

This might be something like Browse Aloud, which is a really good add-in for dyslexic or cognitive impaired users, or you might provide a signing avatar. If you have a chat area, you might want to offer video chat for hearing impaired people to do signing chats, like the Yahoo chat rooms, for example.

There are a lot of decisions you can make about how you go about how you go that extra mile for certain groups, but those are the only add-ons you do. The main site is not ghettoised at all, it’s just an inclusive site that’s been designed to best practice.

Lynda : Can accessibility audits be done in-house or should it be outsourced to specialists? In other words, is there a reliable, comprehensive checklist (for example, Dive Into Accessibility’s “30 Day Guide to Making a Website Accessible?")

Robin : They can certainly be done in-house if the expertise is there. There’s no reason at all not. The WCAG 2.0 Guidelines (Web Content Accessibility Guidelines) are a much more pragmatic approach to accessibility and there are some good testing techniques in there.

Otherwise Web Aim (Web Accessibility In Mind) has got a really good checklist which is much more up to date than the Dive Into Accessibility one. I would point people at that first for a checklist that they could use in-house.

You can’t just do a testing tool, for example, like run the accessibility toolbar over it, and What Cynthia Says or something like that, and then just use the automated tool report as the full picture, because it’s just a small portion of it.

So you need to do a full manual accessibility audit. You need to have the web accessibility toolbar, the colour and contrast analyser toolbar. You need to have a screen reader like NVDA present and preferably some more assistive technologies, like Dragon Voice Recognition. There’s no reason at all why you can’t do it in-house, or you could come to us or another organisation that does independent audits and we would look at a targeted cross-section of their site and send them back the report.

Lynda : It sounds as if it’s almost more cost-effective to outsource in that respect, because you have to get in a lot of software and also train up key members of staff?

Robin : Well, I would say if developers can’t audit to WCAG, they can’t code to WCAG either. We would definitely advocate all the team getting up to speed just for all future projects and the daily maintenance of the current sites they’ve got. They need to know about accessibility, and we can come in and do in-house training if required, but sites like Web Aim have got a really good set of resources for people that are at the beginning of the learning curve and can readily get up to speed.

Often why clients come to an organisation like AbilityNet is to get the last word on accessibility, because there is a lot of room for interpretation, especially if you’re at the early stages. It’s quite a complicated area, so that can short circuit the process, probably quite cost effectively, if they get the first report from us or another organisation like ourselves, and then they can compare that to the Guidelines and see how they can interpret them in the particular context of their site. Other organisations get us to do it on a quarterly basis, so it’s whatever is deemed most cost effective for a particular organisation.

Lynda : How can I persuade my manager to send me (and other team members) on an accessibility course? In other words, what are the benefits of training team members into accessibility best practice?

Robin : Obviously, depending on the size and the scope of the site that you’ve got, outsourcing the audits etc., may not always be the most cost effective way.

If you’ve got any number of teams or a big web team, it might be more cost effective to send them on a course to get trained up on doing the auditing etc., themselves, or to get an organisation like AbilityNet to come in and run an in-house day or series of days.

That obviously would be preferable, because if you’re not up to speed on how to design, develop, code to accessibility standards, then you’re always going to be creating inaccessible sites so that even if you get to a third party organisation like ourselves to audit, the audit’s always going to come back saying you’ve got 58 mistakes here, so you need to get up to speed somehow, whether it’s via training from an external company or trying to get up to speed internally yourselves.

Lynda : It’s never cost effective to retrofit. Once a product’s launched, it becomes much more expensive to fix up the errors than it does to integrate accessibility as you go along.

Robin : Absolutely. I think on a new build, it’s 2-5% additional to factor in accessibility. If you compare that to the ROI, it’s chicken feed really. The Legal & General website that we helped refresh for accessibility, had an immediate 90% increase in online insurance sales.

If you retrofit, it can be hugely expensive and that’s where these legal claims – like the Sydney one – came in. They said it would cost 200K AUD (Australian Dollars) to retrofit for this blind chap to be able to follow the Paralympics. When the court got an expert witness in and they did the analysis, then it turned out to be 20K AUD. There is a big difference of opinion there. But nevertheless, it wouldn’t have cost them 20K AUD if they’d have factored in accessibility in the design and throughout the development process.

Lynda : Which team members would benefit most from an accessibility training course - from the perspective of a digital agency?

Robin : You’d ideally want to get everybody involved, including the marketers, because for people who are involved in digital marketing, it’s even more high pressured there. They’re having to turn campaigns around in say 9 weeks, and accessibility’s the first thing that gets knocked off the checklist because of the quick turnaround and – they would argue – the ephemeral nature of the campaign.

I would definitely get everybody involved and we go into organisations and do training for management and designers, editors etc., all in the same room in the morning for general awareness. And then in the afternoon, we’d do more specific for the techies.

Lynda : How can copywriters benefit from accessibility training?

robin : Yes, definitely. If by that, you mean editorial, then yes, definitely, because there is a significant amount of issues to be considered by people who are writing copy. Not just from a typography point of view, choice of font size, font style etc., because even though they’ve got style guidelines, it isn’t a designer issue because the copywriters are creating the content on a daily basis, but also from a language point of view, simple whilst still appropriate language.

They need to consider the fact that there are 15 million people with literacy difficulties in the UK, and for whom English isn’t their first language; there’s obviously a dyslexic community on top of that of (6 million) and then you’ve also got the people who have a hearing impairment and who are BSL (British Sign Language) users, and they have issues with grammar, and in effect, literacy issues as well, because BSL is their first language. They don’t know a lot of the vocabulary of written English, and there you can offer a glossary of terms, or BBC for example, in their cookery section, wouldn’t use the word “marinade” in a recipe, because that isn’t in BSL. So they would say “leave in sauce”.

There are a number of things -if you’re aware - that you can make sure that you can make sure you do in an inclusive a way as possible.

Lynda : Any suggestions for how I could build a sustainable accessibility infrastructure within my organisation?

Robin: I think having a hard hitting awareness session to make sure that everybody sits up and you’ve got buy-in at all levels, and then you need to make sure that that is then translated into action. A lot of the time top management hear about the ROI, etc., but at the bottom line they want to make sure that they’re compliant and they can tick the boxes for the DDA (Disability Discrimination Act), in which case you need to make sure you’ve got a number of things in place.

You need to do an internal – or external – review of all your systems, because we’re not just talking about websites here; we’re talking about intranets, we’re talking about internal applications and we’re talking about all your channels that you communicate with your customers, etc., and once you’ve reviewed all of those and you know where you are, then you know how far you’ve got to go to become “compliant” or accessible.

Then you’ve got to have a road map, because it’s not enough to just say oh well, we know where we are now. You then need to have a roadmap and defined milestones over the next, say, 18 months to reach minimum accessibility across all your systems. You need to stick to it, so that if anyone comes along and says your website isn’t accessible, then you’ve got this roadmap and you can demonstrate that you are committed to accessibility and you can give a definite time frame to that individual.

It’s a kind of a mitigation approach, I know, but it’s also a pragmatic approach. And because no organisation I’ve ever met is accessible across the board, then that is the first thing that we would recommend an organisation do, a kind of internal audit and then get a roadmap to minimum compliance.

Lynda : It seems to me – and that’s probably because I come from a digital agency background – that organisations often need an accessibility champion, and one of the people most suited to this, I would say, is the usability specialist. Do you agree?

Robin : Yes, in many organisations there is an accessibility champion. I know many FTSI companies we deal with where there is a definite accessibility champion. It’s separate from the person with the usability remit. But there’s absolutely no reason, bearing in mind the significant overlap of - or even one and the same nature of accessibility and usability – for the accessibility champion not to be that person.

It’s often useful to separate them just so that people can be aware or to have the same person, but specify them both in their job title.

Follow Robin Christopherson on Twitter for updates on seminars, lectures and general accessibility news and issues.

Links I'm Liking

Three bugbears that I’ve noticed crop up time and again when reviewing a website prior to a redesign proposal are :

a) using tables for layout (accessibility)

b) using dropdown menus instead of left hand vertical menus (usability)

c) using relative width (liquid design) and getting it wrong with long line lengths (legibility)

Here are some links relating to these issues, which I have found either entertaining, enlightening or inspiring :

Why tables for layout is stupid - a fun CSS tutorial incorporating correct and appropriate use of tables

Dropdown menus; no thanks! - accessibility/usability isn’t just about correct code, it is also about the way people interact with computers - a good example here is the elderly person trying to click on a constantly disappearing sub menu within a dropdown.

Finally, liquid design. There seem to be a plethora of articles (including Jacob Nielson’s advocation) extolling the merits of relative width. All of these articles are dated circa 2006. In my experience, many websites get it wrong - by not designing specifically for this approach and mostly for not limiting the resultant line length. But - oh joy! - I found a website that gets it just right : simple.art

The Invisible Artisan

Personae are a potent business intelligence tool that are frequently misunderstood, misconstructed or assumptive. The consequences of rolling out "made up" personae as fact will ensure that any user experience is based around a premise.

Perhaps it's best to start out by defining what a persona is not. The idea that a persona is created by looking at a demographic segment and giving it a lick of personality veneer arouses dismay within any self-respecting UX practitioner.

I've seen many a personae constructed subjectively, outside of UX; hurriedly put together within pitch documents to demonstrate an awareness of a particular organisation's users. Having won the pitch, these personae are not interrogated, but believed by client and agency to be correct. They then get handed to IAs who use them to create user journeys.

Another mistake is for an organisation to predefine who they think their personae are and how many there are. This can only result in forced and diluted stereotypes that serve as a kind of pale doppelgänger. Or worse, too many personae, many of which are shades of each other. And from a business point of view, this becomes an expensive exercise that only distracts and confuses. Most persona investigation exercises yield around a handful of primaries, the median being around three.

The interesting thing about personae is that you never know what will emerge from your quantitative and qualitative data. There is something almost magical in the way archetypes emerge from the clusters of attitudes and behaviours of groups of people that you interview.

It is vital that your personae are empirical if you are to develop an insight into designing truly user-centred interfaces. I use a mixture of primary and secondary research, because it's important to validate what you discover through focus groups or interviews against data captured from surveys and the like.

Keeping an Open Mind

Remaining receptive means that you won't influence your subjects, who are often vulnerable to giving what they believe to be the right answer - after all, you are paying them to participate, and people do like to please!

This predisposition is often seen in user testing, where participants will give glowing reports of their experience on an interface, despite observational evidence to the contrary.Setting the Criteria

It's important to establish beforehand, however, what you are hoping to achieve from your research. Are you trying to capture attitudinal data, are you investigating the type of content they would like to receive? There is a delicate balance between allowing people to wander off into delicious tangents, and bringing them back to the core of what you are trying to investigate. Allowing people to "flow" can often allow for deeper insights that may not have been uncovered within a rigid facilitation framework.

Another thing to watch out for is the group dynamic within focus groups. Some people like to lead, whilst others are passive. Ensure that everyone gets an opportunity to contribute.

It's a good idea to work in a small team when conducting primary research, so that you have several sets of eyes and ears, and can bounce your observations off of each other.

Identifying the Persona

After several focus groups or interviews, patterns begin to emerge. You notice that people across groups begin to show similar attitudes or needs. Your persona becomes a composite sketch of these findings. While your persona itself is not "real", it has its basis in real people...

Once you have what you believe are the full set of personae, it's time to discover who your primary personae are. These are the personae that, if you design for them alone, would in some way disenfranchise another persona. Analysis will reveal who the primary personae, with their distinct needs, are.

Your secondary personae will sit beneath, or between your primaries. These are the people whose needs are satisfied by designing for the primaries, but who also have additional, sometimes less important [from the business perspective], needs that can be easily accommodated within the design.

You may find that you have other personae who, while interesting, are not necessarily part of the main audience as defined by the business goals. For example, these might be people who wouldn't use a digital artefact for one reason or another. They help to form the wider picture, and these are your third, or tertiary personae.

Once you have created your hierarchy, you are ready to use your primary personae to inform the design process.

They become the voice of the user - a reminder to let go of personal whims or cognitive biases and design authentic user-centred products.

As a business tool, personae can be used across disciplines to enlighten and inform production. The insight that they provide means that a brand is communicating directly with people and not "consumers". It's never a good idea to have a static view on personae - each new project requires new research. If the business proposition changes or grows, new research must be conducted. A new game, a new hand of cards, so to speak.

Since personae are constructed from real people, it's useful to recall focus group participants or interviewees to test and validate as the product is developed.

The fruit of a tree is only as sweet as the strength of its roots; it's a grave mistake to be glib about what real people do and need.

And finding out what real people's goals are is simple. Just ask them!