This is the slides from the talk Rich and I gave at DrupalCon Copenhagen, slightly modified for Slideshare.
More information: http://cph2010.drupal.org/sessions/imaginary-users-can-save-your-drupal-site
7. Imaginary users or “personas” Personas are not about brainstorming. But on your Drupal site they'll end up with minds of their own.
8. Each team member is focussed on the bottom line. Everyone's idea of the bottom line is different. “ On the Web, usability is a necessary condition for survival.” — Jakob Nielsen Why this solution?
9. Personas in five steps Name: Dominic Thomson DOB: 16 January 1964 1957? Address: ? Five step plan?
20. “ Use standard form fields. People prefer page elements that they recognise.” “ Don't have dropdown menus. People don't like them covering up content.” “ We know there are some people out there who hate the things we love... but not sensible people.” — Steve Krug 2. Conflict resolution
23. What do we want them to do? Load /attendees Assert some attendees on page Type “stacey” in the “ name” textfield Click “apply” and wait Assert text exists “ J-P Stacey”
24. What do we want to find out? METRIC WHAT UX HOW
25. “Nobody knows you're a dog” Email address Blocked user Persona role Username (Password)
26. Preparing personas for testing Live personas are blocked their passwords are all ultra-secure and they have non-existent email addresses Your staging personas must be unblocked their passwords should be memorable and all emails sent to you
32. “ As a normal user I would like to see a list of the content I've recently flagged when I log in so that I can revisit content I find interesting ” Scenario(s) for done Log in; flag an item of content; log out and in again; check that the item is on profile page Persona-driven specification “ As Dominic Thomson I would like to see a list of the content I've recently flagged when I log in so that I can revisit content I find interesting ” Scenario(s) for done Dominic Thomson logs in; flags an item of content; logs out and in again; sees that item on his profile page
35. Test-driven development Client requests functionality Record test as persona Test fails Build functionality Test succeeds Client signoff & deploy Most or all of team agrees: success = done
43. And thank you! Creative Commons attributions from Flickr Bulb: Tim Cummins; List: jcrawf3; Portrait: adubber; Notepad: calsidyrose; Desk: keithius; Tesla coil: willivolt; Hand: Damon Duncan; Penguins: nouqraz; Team: atomicshed; Buttons: spikenzie; Pepperpot: hien_it; Elastic dog: quirkyrocket … icon fonts by somerandomdude http://www.torchbox.com @torchbox @jpstacey | @middric
44.
Notes de l'éditeur
Thanks for coming! As it says here, and as you're hopefully aware of by now, going to talk about imaginary users. What that means shd become clear in a bit We are J-P Stacey and Rich Middleditch, and we're on the Drupal Team for Torchbox. which is a web development company that works primarily in the NGO and not-for-profit space. We're primarily developers, but we do architecting, specifications and fixing both bugs and bad UX
Before we start I wasn't quite sure where this slide should go. Wasn't quite sure where a lot of slides should go So you're going to see this slide twice. To be honest, you're going to see a few slides twice. But please vote on our talk when we're done. It's like good democracy, right? however you vote, just vote. But if you can be nice about us, that'd be great.
I want to begin our excursion into land of imaginary users with an idea. Your company might work for a client, maintaining THEIR Drupal site. Or your company might maintain its own. Someone who has a stake in the website has an idea, and they want the web team to implement it. Everyone has ideas. Some good, some nsg. Some groundbreaking but might not work; some boring but probably will work How do you typically go from an idea to something on a website, something tangible and usable?
Traditional approach. Start with a “team” of: idea person (maybe the client's boss), client contact, PM, designer, developer, UX person etc. Contact's boss sees Facebook Connect Contact asks for “ a Connect button ” PM works out contact's wishes Wishes become functional spec Designers mock up functional spec Developer builds designs as code Everyone iterates round and round Client gets signoff from boss Developer deploys. We have to hope that, somewhere here, someone has remembered the USER . Nobody has overall “ownership” of the work. Nobody has love invested in the finished product. Let's fix that.
Traditional approach. Start with a “team” of: idea person (maybe the client's boss), client contact, PM, designer, developer, UX person etc. Contact's boss sees Facebook Connect Contact asks for “ a Connect button ” PM works out contact's wishes Wishes become functional spec Designers mock up functional spec Developer builds designs as code Everyone iterates round and round Client gets signoff from boss Developer deploys. We have to hope that, somewhere here, someone has remembered the USER . Nobody has overall “ownership” of the work. Nobody has love invested in the finished product. Let's fix that.
Traditional approach. Start with a “team” of: idea person (maybe the client's boss), client contact, PM, designer, developer, UX person etc. Contact's boss sees Facebook Connect Contact asks for “ a Connect button ” PM works out contact's wishes Wishes become functional spec Designers mock up functional spec Developer builds designs as code Everyone iterates round and round Client gets signoff from boss Developer deploys. We have to hope that, somewhere here, someone has remembered the USER . Nobody has overall “ownership” of the work. Nobody has love invested in the finished product. Let's fix that.
Let's invent someone to love this work, to own this work. We're going to create an owner, from the ground up. He's going to be an imaginary user. A user persona. Let's flesh t out and give t personal details, a life, a back story. Make them the functionality owner on the team.
[CLICK] Team members tend to focus on own domains and champion their own agenda This is understandable: they're looking after what they see as the bottom line. Efficiency, in their own domain. [CLICK] Problem is, everyone's looking at a different bottom line. Using personas focuses the team on the USER's agenda The user doesn't get everything they want, but it means that user behaviour is king. The site must provide a usable way to achieve the goal. [CLICK] If a website is difficult to use, people leave . If the homepage fails to clearly [indicate] what a company offers and what users can do on the site, people leave . If users get lost on a website, they leave . If a website's information is hard to read or doesn't answer users' key questions, they leave
So I'm going to talk about this guy, Dominic. Dominic doesnt exist yet, but we'll sort that out in while and JP will show you how we can really bring him to life. In the meantime, how do we prepare for Dominic? Ideally we should start to find out about our users at the start of a project, during its discovery phase. Our aim here is to identify the key users, not necessarily all your users, to identify the kinds of activity they will perform and to ensure that the entire project team is on board Its pretty straightforward to do this, and you can spend as little or as much time and resource to create a persona as you like. You can slim it down to a simple <click> 5 step process.
For personas to be successful they must be adopted by all members of the project team. Acceptance internally is often easier than getting acceptance from clients. Without client acceptance the factors for success and completion are muddled and the sight of what users need can be lost Talk about personas as if they were real people Put up posters, create ID cards, bring cardboard cut outs to meetings, whatever is necessary Adoption is achieved when a team member says “Adam wouldnt do that” and no one questions who Adam is Make the personas memorable and as realistic as possible
Your personas must be based on real people. How much time you invest in this is up to you. You can use any or all of: Client knowledge Previous studies Surveys Focus groups Interviews Don't forget to find out about people who may not be the end user but still have a stake in the product, perhaps indirectly We're trying to avoid the 'elastic user'...
, someone who's needs and motivations change depending on who is talking about them (license to build what you please under the guise of 'for the user'). Hopefully we'll also stop the developers and designers of the site from projecting there own goals onto the end product and losing site of the real needs of a user
Its important to remember that a persona is a spokesperson for people like themselves and not an individual. They represent a group of users <click> and as such its necessary to identify the groups or behaviour patterns within the research we did to find the users.
If the project is large enough, it is worthwhile splitting your personas into primary and secondary groups. <click> Primary personas are those which have goals which are pretty much unique to them, if you're lucky some of their goals will overlap and reduce your workload. <click> Secondary personas are those which have all of their goals achieved by one or more of the primary personas OR their goals need to be considered but arent as important for success. Primary always wins. Anytime you have a clash between a primary and secondary the primary must always win, they're the must important users.
With the information gathered during our user research, and the behavioural patterns we've discovered we can now build our persona. This is a collaborative process and the client as well as internal teams should be involved to increase buy-in. So lets build Dominic... Avoid baggage from real life Dont call her Jane Doe Try not to use online American name generators Use a naturally shot photo Flesh out the bio, make it interesting – but realistic Give the persona some motivation
A persona is typically made up of: Name Photo Description Motivation Goals Frustrations Behaviour Scenarios Additionally can include: Use of digitial tech Relationship with client and clients competitors Triggers for visiting website What he/she gets from the client What the client wants them to do
So again focussed on the bottom line - how do we make use of this tool we've built?
I've tried to divide up all the things you can do. Help you to write specifications: are you muggins? ask all team members if need be 'WWDD?' Help you settle arguments: agreed if not explicit set of 'soft standards' Extend your team: like having an extra person to offer ideas etc. Test your results: people or machines as we'll see pretend to be the personas.
If the child has hold of this list, they won't tick things off straight away. If the parent has the list, they might wait for the kid to have a nap and tick them all off for them. The user persona is a trusted team member who can provide the test of whether a specified piece of work is done or not
Anyone in the keynote earlier might remember that Jamais Cascio said that software development is inherently a political endeavour People project their own prejudices onto the user base as a whole. Real example from a developer Real example from a client But Dominic is different. Dominic has an agenda, like everybody else on the team. But Dominic's agenda is putting user behaviour first. If everyone agrees to put user behaviour first, they will have a hard time disagreeing with Dominic.
Print your persona details. Put them up on the wall. Argue about them. Defend them. Talk about them with people outside the project team. The right decision is hidden in how the persona is likely to behave. Here we see Paul being shown round a number of longstanding personas for one of our clients.
Most exciting for us as predominantly site builders are the opportunities for using personas to test site functionality directly. Let's make the persona actually exist, or as close as possible to that.
What might we want a persona to do? We want the persona to move around a website performing actions to make observations and check things work properly and to do this repeatably and often, at a later date. Let's say I want to basically Google myself. I want to check someone can find me on the DC CPH website. If I were saying out loud what was involved...
on the Internet nobody knows you're a dog Username - convention makes it easier to test Email address - not so important as we'll see in a sec Password - make it cryptographically strong, unguessable Block the user. Who knows what perms your personas might have? They're the same security risk as abandoned accounts, so best make sure they're switched off. Role - keep track of personas using roles. Delete them all if you're worried about security.
I didn't want to put any code in this talk But this is here for completeness. It lets you create persona accounts only once on your live site, blocking them for security purposes, then use them quickly on your staging site without worrying about security. If you really don't want to know about code, unblock your users by hand and put your fingers in your ears and close your eyes now! Put this in a module. Get someone to show you how to. Ask me.
I didn't want to put any code in this talk But this is here for completeness. It lets you create persona accounts only once on your live site, blocking them for security purposes, then use them quickly on your staging site without worrying about security. If you really don't want to know about code, unblock your users by hand and put your fingers in your ears and close your eyes now! Put this in a module. Get someone to show you how to. Ask me.
A few people here might have heard of Selenium A few of you might have used it If you used it three years ago, you might have dismissed it as a bit clunky Complicated, long-lived project in lots of different incarnations. Rather than discussing what it IS...
Open IDE and start recording Log in Dominic Thomson Log out DT Go back and add assertion Run test Run test slowly - check you can! Save test
Quick testing offers you a robust check on how reliable your functionality is. You can run the test over and over again. Dominic will tell you a rapid succession of yes or no for these tests. Slow testing means you can sit and watch the user perform the tests. You can see how easy the user journey is, how nice the user experience is. Say:I'd never click on THAT. Although you will get the same single yes or no out of the tests, Dominic is actually telling you what he thinks about the site. You can see it through his eyes, as if it we were over his shoulder. You can decide on the basis of a slow test whether or not a journey is possible but also whether it is LIKELY. Quick testing gives the metric, slow testing shows you user experience. Or: quick is WHAT, slow is HOW.
Assume you've created SEVERAL personas, and you're starting to use them Where do you go from here? How do you make your persona use open-ended. After all, this is all about the bottom line. If you've invested in the personas, you should get as much value out of them as you can. Here's some ways in which you can get your time's worth and therefore your money's worth.
Put your persona into the spec as early as possible. Here we see an example of an agile spec, in the form of a user story. These already place the emphasis on the user's actions. I've colour-coded the bits: But let's explicitly add Dominic to the story. Suddenly it becomes very concrete. The scenario to be tested can now be converted unambiguously into a Selenium test within minutes Ask yourself what would Dominic do. Ask the team.
You can't cover all bases at the start. As you write a spec, you might feel Dominic is the wrong person to test it. Be prepared to create personas later. Be happy doing so
How many times has a client reported a bug, but the developer can't repeat it? The bug goes back and forth. It's inefficient. If someone spots a bug, repeat it with Dominic Thomson. Record a Selenium test and attach it to the bug report. Here we see a Trac ticket. Trac is etc.
Dominic can be at the heart of your specs and bug reports, and also guiding your development. Rather than writing functionality and then only recording Selenium tests afterwards, or when sthg goes wrong.... Go through slide
It's great that you can get Dominic to test the site for you when you want. But what if you want him to test it all the time? And on a machine that isn't your own laptop? If we step up to a different version of Selenium - Selenium Core - a bundle of Javascript you put on your server - we can do that.
This is what we do in Torchbox. When we're developing heavily on a site, we have a laptop open running tests as all our personas. Selenium Core in sites/all/libraries/selenium Greasemonkey script restarts tests every 30-40 mins Yes, a suite of 50 Selenium unit tests can take that long!
People get bored of a laptop in the corner. They start to ignore it. We need emails or a big red flashing light, but ONLY when sthg goes wrong. The next step is to have Selenium tests running all the time. All night. Without a laptop. Dominic testing a site all the time, and to have Barbara testing the site, while Steve and Barbara test another client's site. And only emailing us when something goes wrong.
We do this with Selenium Remote Control. This lets you run tests on a server in your basement. Here's our servers in our basement. The left-hand one is Flitwick, which can run Selenium tests remotely. Even though it has no monitor, it can open and close browser windows over and over again and run our tests. We can send tests to Flitwick using Python. We can turn Selenium HTML files into Python using PySelenese, a project I've put on github. And Flitwick can send tests to itself, either all the time or whenever someone checks in some new code, at any time of day or night. This is our current project in Torchbox and we're nearly there.
I said you would see some slides twice. Dominic has helped us write specifications. He has simplified the requirements because he's someone to point at when we need to. He's a shorthand for more. Dominic has made it less likely we will argue about the site, because if we want it to be successful we know it needs to be successful for him. He is a metric for whether or not an idea is right. Dominic is a presence in our office on the walls and he takes the pressure off other people by fulfilling the role of imaginary arbiter. And Dominic can test our site constantly, twenty-four hours a day, without pausing for meals, sleep or to watch The Wire.
You've seen this slide before as well. But now we're going right back to the beginning. What do user personas mean for that idea that someone had? Well, people will always have ideas. And some will be good, and some will be bad. But with good user personas you have someone who might tell you if it's good or bad will help you work out how to implement it will keep tabs on whether the work is finished will make the work easier to do and more robust and will keep an eye on your website for as long as you need them to, like your own personal testing fairy. And for all those reasons, imaginary users can save your Drupal site.
So thank you, Dominic, for everything you've done for us today [ad lib] no, no, man, thanks [CLICK] I'll speak to you later in fooBAR, yeah?
And thank you. Thanks for listening. And thanks for DrupalCon CPH for letting us speak! We hope you're now as fired up about good usability as we are. If so, then you can get in touch with us at any of these locations and we'd love to have a chat with you. We are developers who have got over ourselves. And rediscovered the user. And, really finally...
Be awesome! Evaluate this session Number 9 1 7 8 !