Lightweight personas

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:

  1. Tales from the trenches: Essential test case design