Summary
In the following post I discuss the concept of lightweight personas, and look at how they can be used to prompt test idea’s. I explain the differences briefly, between a traditional persona, and a lightweight one. I then go on to give examples of real life lightweight personas and demonstrate how they can be used to inspire idea’s.
Personas explained
In my last post about test case design techniques I’d mentioned the topic of lightweight personas. I think it’s probably worthwhile discussing their usage as a test technique, and being lightweight, this shouldn’t take too long.
So what is a lightweight persona and how does this differ from a normal persona? Well your typical usage of a traditional persona, would be the creation of an actor, a description of their personality traits, and how they’d interact with your system. The actor Joe Smith for example, could be a user of the system who is easily bored, so would generally like an application to fulfil his needs very quickly, with little thought or understanding of its features required on his part. This would be a traditional, although very short persona. Generally they would be expanded a little, and might be accompanied with a fictional picture of that person.
A lightweight persona is generally a one or two word description of a type of user who will interact with your system in some way or another. Essentially, the persona list becomes a checklist. This persona checklist can be very useful for the creation and validation of test cases, requirements, test/business deliverables and goals. With a mental model of personality traits, or experience used in combination with the user types, you can rapidly generate excellent test ideas around a system. Simple huh? It really is, and lightweight personas can be extremely powerful.
If you plan on collaborating with others, perhaps in a group brainstorming session, a simple yet very powerful technique that you can use, is to invoke lateral thinking within the group. This is easily done, by simply listing each lightweight persona on a highly visible area in the room, such as a whiteboard, and for each persona use a different colour. From simply listing each persona, in different colours, you’ll engage the creative side of peoples brains in the group, making them much less prone to linear thinking. It sounds a little silly, but it really does work.
Example lightweight personas
So lets look at some real life examples of lightweight personas. The following are personas I’ve been using at MaidSafe to flesh out requirements scope for future releases:
- User
- Administrator
- Seller
- Buyer
- Hacker
- External Developer
- Tester
As I said each lightweight persona is usually one, or two words at most. If you develop these on your own they will make perfect sense to you, however if you’re using them in a group, it’s best to verbally explain each users role briefly to the others. For example a hacker would look for ways to gain access to a system, whilst a seller may think of ways to help sell the system.
The examples I’ve provided are mostly straight forward, and I’d assume that most people when they think about ways to test the system, would at least always consider how the end user would interact with it. When we start to consider other people involved in the product, we begin to take in more important aspects, which sometimes some might not consider as their responsibility. Test is all about providing valuable information though, and I’ll provide some examples which may highlight why it’s important to have a holistic mindset when approaching testing of a product. When I say holistic, I mean the whole system, from a simple standalone component, to business goals.
An ocean full of test ideas
So what are these important aspects, and why should I care? Well, the seller for example is primarily concerned with how he can best sell his product. If we think of possible factors that might affect the tests we write or execute, we’ll begin to consider important business level decisions, such as how something impacts the company image, or the businesses ability to gain credibility.
At MaidSafe, being a small start-up, some of the important testing activities that might gain us initial credibility with clients, are the validation of claims we state. One example of a MaidSafe product claim is the ability to gain significant network performance improvements, when using MaidSafe or our sister company Sigmoid’s software. If we can prove this claim internally, or better still on a potential customers site via credible testing, and reporting, we stand a much better chance of selling the product to other potential customers, as we now have a valid benchmark to show them.
Another example would be the impact to a companies image when thinking in the seller personas mindset. Let’s imagine that a customer beta trial of the product we’re testing is looming. Perhaps it’s a month away. Being responsible for testing the product you should know, or at least have a rough idea of its stability, and perhaps some notion of how far away it is from being fit for release. Let’s say the owner, or some other influential party finds another suitable candidate to beta test the product. Only this client wants it the product two weeks sooner than the other to test. Now it may be ok, or it might not, however the companies image is at stake here, and whilst a level of defect feedback is expected from the customer, giving them something which is in no fit state for customer trials, may have a serious negative impact to your companies image. Your job as a tester is to provide valuable information about the product, and in this case a simple “Stop! We’re not ready!” may well do the job.
Administrators, are all about managing, modifying and being aware of important aspects of the product. With an admin hat on I can easily spot gaps, or potential flaws in the system, such as bottlenecks in administrative capabilities. Likewise, I could simply spot an admin type feature that has no useful outcomes, and question why it’s even there.
Buyers are concerned with useful features that solve their problems and don’t cost the earth to purchase. As a tester, thinking as a potential buyer, I might ask myself “Well, is that it?”. Thinking in terms of value to a potential buyer might see you considering what makes your product any better from the rest of the competition. This may lead to fresh ideas, or the highlighting of specific risks with designs, perhaps even the prompting of analysis of the competition, or at most a complete re-design. Not my role you might question? Well I beg to differ, and any good tester will consider all aspects of the business, reporting any issues found swiftly. Think holistically remember.
Hackers will look to gain access, disrupt, or even bring down your system. As a tester, having this persona in mind can highlight potential areas of weakness. Being involved in technical design meetings early on in the requirement scoping phases, can really help with this mindset, as you become more aware of potential weak points in the system. Even if you don’t highlight those flaws there and then, (as you may have not been aware of them) having this persona in mind may bring them to light at a latter date, and possibly save your company from potential embarrassment, or indeed money losses. Even as a trigger heuristic this may lead to you prompting new business tasks such as external security audits, which if we tie with the seller persona, leads to credibility, and as a result potential sales.
An external developer could simply be a contractor that you’ve hired to develop some specialised feature, or perhaps to help speed up internal development. They could even be someone looking to make use of your public facing API’s to develop some 3rd party product; think Twitter/Tweetdeck, or IPhone/Apps. As a tester, thinking as an external contractor developing code, I’d obviously flag up an obvious risk about what happens, once this contractor goes? Who maintains the code developed? Did some knowledge transfer occur prior to them leaving to help smooth the handover? Is there decent documentation (if needed)? Obviously the outcome of these questions will have a direct impact on quality, either for the better, or worse. Alternatively, external developers who are looking to build their own applications, which will make use of your products public facing API’s, obviously flag up more concerns. Do these API’s fulfil their needs? Are they properly tested? Being a black box to this external developer, we really want to ensure that they can easily find what they need, without much effort. So a well structured, readable, usable and documented set of public API’s is essential.
I’ll not bore you too much with the tester persona, as it should be pretty obvious. We are concerned with risks, effort, and returns from time invested; after all, testers never have enough time do they? So here we might simply be thinking about risks, such as the performance, or scalability of the product, and looking at ensuring the system fulfils these needs. Perhaps we even look a product version or two ahead. Now extensibility becomes important, and we’ll consider aspects of the system that will be prone to later extension, and ensure that this is possible, whilst still allowing for backwards compatibility, if needed. Likewise testability, might throw up a need for a test harness somewhere, or a script to manage, or mock aspects of the system. Really here, we can think of so much!
Final thoughts
So you can see that by considering the types of actors who may interact with your system at some point or another, and by putting some thought into the things they might do, or indeed the attitudes they might have, we can quickly model powerful test ideas around these actor personas. I use these all the time when generating test conditions for new features to be tested, or for generating high level test idea’s. I also find them extremely useful for determining risks.
I hope if you aren’t making good use of lightweight personas already that you’ll find them useful. Thanks for reading.
Related posts:
Yet another good blog post
Darren, Having a checklist of end-users helps a lot in triggering test ideas and sadly most of the testers fail to question “Who are the end-users of this product?”
I liked the way how you have drilled down by explaining about those personas individually.
Would love to share this blog post with as many testers I can.
Thanks,
Santhosh Tuppad
Hi Santhosh,
Thanks for the kind words
From my experience talking to fellow testers, I’ve found that quite a lot talk about thinking like the end user, however when I ask what this means to them, their response differs greatly from my perception of thinking, or indeed testing like the end user.
I think the basics of trying to adopt a user mindset is good, and this is what most do at least, however they could go further with some investigation into techniques and studies, which will unearth a lot more useful information. This will make the information you provide to stakeholders, much more valuable.
Consider the complexity of a scenario a user has to execute. Something could be extremely usable, and in fact make the user feel much more satisfied in the end. This scenario might involved a degree of learn-ability, in a given context, to a certain level, and the extent of user learning might vary. If a user doesn’t need to use your application, the acceptable level of learn-ability might be very low. Or if the user worked for an organisation who’d paid good money for a product, then the acceptable level of learn-ability would now be much higher, but only to an extent.
TweetDeck is a good example of borderline learn-ability. At the bottom of the application is lots of tiny buttons, which when hovered over will reveal what they actually do. I’ve no idea what any of these buttons do, but I’ve used TweetDeck on a daily basis, for over a year. Now these buttons may be very useful, or perhaps they are just waste, I don’t know, since I’ve never felt the need to learn what they do. The key point here, is that TweetDeck, visably delivers the minimal key functionality that a user needs, with next to no learn-ability needed. The polish, or perhaps the really useful features (I don’t know, or care) blend in at the bottom of the deck, but require a higher level of learn-ability. So user can get bye and still enjoy the product. If they want to learn about it a little more, they might make their experience even more enjoyable.
This is only one example of thinking in the users mind set, there is so much more for people to learn, and I myself am still learning. So people can, and should spend some time investigating, and learning from the many excellent resources out there on the web. It’ll certainly help their company deliver a much more usable product, to the extent of stakeholders listening, and actioning the feedback provided.
Thanks, for taking the time out to comment, I hope I’ve not rambled on too much
Cheers,
Darren.
A timely blog post indeed.
The team of writers here are, now, looking at using a lightweight persona to help us frame our documentation and specifically as a tool when discussing customer/user needs.
I’ve worked in companies where we had full, rounded personas but, for me, the business benefits weren’t fully realised (they cost a lot to produce and we didn’t use all of the information), so a lightweight approach is a good starting point.
Hi Gordon,
Thanks for the comment, and I’m excited that you’re using persona’s for your documentation. That is really cool Although Ciboodle is a forward thinking company, so I’m not surprised.
I think the lightweight approach, gives you the flexibility, and easy buy in from others. Consider the week, or even month worth of work developing detailed persona’s. Most likely this will be a task for one, or maybe two people. Whilst this is on-going everyone else is plodding away doing their daily tasks, then these detailed extensive personas are dropped in, and pushed on them as the next big thing, that’s going to improve quality, and save the company money. That, is the hard sale, and it’s a struggle to get others bought in. Lightweight persona’s give quick visibility and are easy to understand, so people buy in to them more easily.
Perhaps like you say it’ll get them to adopt a more detailed persona at a later date.
Cheers,
Darren.
Hey Darren,
Great post. I like the idea of using the different personas to help identify different areas to test. When we get to a certain stage (e.g. with LifeStuff) it might be good to pull a pilot group of people together who in reality are the key different types of users helping test the system.
Mel
Hi Mel,
That’s a good idea! I guess the hard part will be trying to get that varied user group; hard but not impossible.
When we begin to look at usability trials often the persona types are already available in house.
Take for example your highly technical user who loves the latest trends in technology, and uses Twitter, Facebook and perhaps LinkedIn on a daily basis. We probably have a couple of them in the office already.
Your middle ground user, who knows of some social networking sites and might use one sometimes, but not daily. They tend to get informed of new technology by word of mouth, or perhaps by stumbling upon it accidentally. In our office these might be harder to find, but indeed in large companies there will be many of these persona types available.
The tech-a-fobe (user scared of technology) is certainly not around in our office. They would rather not use the computer much and certainly don’t have a social profile. They occasionally might pop on to read some news, or to read up on something they’d found interesting. In larger companies perhaps there may be a couple of persona types like this.
The good thing is, that most of these types of users are readably available for in house usability testing. Likewise true temperaments will be more accessible since you know these people. So a frustrated user, we’ll know will give an honest opinion on the slightest learn-ability flaw we’ve introduced. If we’d gathered those persona types by surveys, we might have less confidence here.
There are many exciting things that we can, and will be doing when we go to launch our public facing product (LifeStuff) in terms of usability, and I’m certainly excited at the prospect of it all
Cheers,
Darren.
Good stuff Darren. Not so long ago if testers knew about personas at all they were inclined to regard them as something that UX people (who they?) messed around with.
Some people might have known they can be a valuable tool, but trying to sell the idea would be hard if the assumption was that detailed ethnographic research was required to produce any persona that would help in testing. Yes, that level of detailed is required for certain products, but a more lightweight approach is often more useful, or rather cost-effective.
The thing I like about personas is the mindshift it encourages. Instead of testing against the requirements, and simply establishing whether the application meets the organisation’s needs we start to think about how the user will actually work with the application. Users, especially customers, couldn’t care less about the organisation’s needs. All they worry about is doing their job, or buying the service they want.
It they’re approaching the application with the attitude “how will this help me do what I want” they’re likely to try and make it behave differently from what the designer assumed. I particularly like the way you bring in hacker personas. They don’t have to be as technically savvy as a hacker. A bad guy on the payroll could be even more destructive, and if you put an opportunity in somebody’s way with a vulnerable application then you could be tempting them over to the dark side.
Hi James,
Payroll baddies, I like that, and you’re correct, that is equally important. After all we could have the most secure system in the world, with internal users making a mockery of it.
The mindset shift personas give, is incredible. Even when you think you know it all, and then look at your check list of user types, suddenly you realise that you’ve missed some key fundamental issues.
Another good one to throw in the hat, when thinking in these persona types, is to ask yourself for each one, “What problem is this trying to solve?” After all if it’s not solving a problem, then is it really a viable product?
As for these UX guys; how do we stop that mentality? Really, I’m completely with you there! Perhaps we just have to hire some of them to coach others
Cheers,
Darren.
Good post, D.
The more I think about personas the more I wonder why we (that’s a collective ‘we’, by the way) didn’t entertain them sooner. As James correctly mentions above the process of changing the mindset can easily expose a world of valuable information as opposed to simply taking a ‘vanilla’ approach of simply verifying requirements.
I’ve been giving some thought to lightweight personas in my own organisation but also how to present it in a way that immediately makes sense to people who are not experts in test, software or indeed UX. For some reason, I started thinking about the “Mr Men” by Roger Hargreaves (http://en.wikipedia.org/wiki/Mr._Men) as a useful way of encapsulating user personas, but not necessarily limiting myself to the official contingent. For example:
- Mr Messy
A scatterbrained user who frequently mis-types data, makes spelling mistakes and sometimes gets lost when attempting to perform simple or complex actions.
- Mr Fussy
A real stickler for detail who loves nothing better than picking out inconsistencies from one web page to another.
- Mr Lazy
Likes to take the ‘path of least resistance’ when attempting anything and will continually look for shortcuts when trying to achieve his goals.
- Mr Hacker
Constantly looks for ways to expose your system so he can win respect from his peers.
- Mr Angry
Woe betide any application that doesn’t conform to his expectations. Much mashing of keyboards, double/triple/quadruple clicks on the mouse for sensitive items
Anyway, you get thie picture. It may seem a bit childish, but I actually find them a great vehicle for conveying the shift in mindset rather than going into elaborate detail about the characteristics of the user persona in question.
I feel a blog post coming on….
Del.
Hey Del,
I don’t think that’s silly at all, in fact I really like it
It brings a fun perspective to personas. Perhaps you could stick images of these Mr Men, on a visable area of the office to get everyone, not just testers considering them.
Looking forward to the blog post
Cheers,
Darren.
There was an interesting piece about Extreme Characters way back in 2000. I’m not sure if it’s something you could apply in quite that way, but it’s the sort of thing that gets the mind working.
http://homepage.mac.com/j.p.djajadiningrat/publications/2000DjajDISInte.pdf
David Travis gave this good warning about the pitfalls of personas that aren’t based on research.
http://www.userfocus.co.uk/articles/personas.html
Ok, that’s aimed more at designers who’re trying to build the product on the cheap, rather than a warning shot at testers, but there’s still some stuff there for us to chew over.
As for dialogue with UX people, it is happening more now. Twitter and blogs like yours are a great way of exchanging ideas.
I noticed that my tweet recommending your blog was retweeted by a student of digital interaction design (hi Virginia!). It would be good to see what people in that field think about testers adopting personas.
Hi James,
Sorry for the late reply. I enjoyed reading both articles, thanks for sharing
Aspects of the extreme characters could fit into lightweight personas easily, by having an emotion check list for each persona. David’s article was interesting as well, but like you say, take what you want from these things you read, as certainly this goes against a lightweight approach, which may indeed be all that is needed, even for UI designers, dependant upon the project.
I almost sure you know of uxbooth.com, I’ve been enjoying quite a few articles posted there over the past year. If not, enjoy
Cheers,
Darren.
Nice post. Gives testers a new perspective to look at users of the system. Sometimes we are so involved in the product we forget to think beyond what we see.
Hi Shilpa,
Thanks, I’m glad you found it interesting, and thanks for commenting
Sticking company or product specific persona’s into your testing model, then printing it out and keeping it at the side of your desk helps spark new test ideas I find.
Cheers,
Darren.