Buyer Personas and User Stories

Website development aligned with website testing

Web development aligned with testing

Website design, development and testing go hand in hand...

Unless the business requirements are clear, how do web developers know what to produce, and what scenario or range of scenarios need to be handled? Furthermore, how will websites or updates get tested thoroughly, unless those who are testing are provided with the same guidelines that the web developers will have received?

A single source of truth

It therefore makes complete sense for the web developers and testers to be working from a single source of truth, instead of each of them having their own opinion about a vague description that was provided.

I actually thought it meant something different!

But there are usually several people involved from the concept to conclusion, such as:

• The main stakeholder who can champion the project.
• The person responsible for each business requirement being documented, so that it's clear what a successful outcome should be. Lines of responsibility are often blurred, but this task might fall to a Business Analyst or Product Owner
• Subject matter experts (SMEs) or Business Analysts can predict how the implementation of one piece could have an impact on something else, so that potential issues can be anticipated and avoided.
• The web developers who will write the code to implement each requirement need to have a clearly defined goal to work towards. In conjunction with the web developers there could also be database administrators and software architects.
• Those responsible for writing test cases based on the original requirements.
• Those responsible for testing, who will closely follow the test cases so they can confidently sign off a successful implementation on a case by case basis, or reject it and push it back to the developers to fix it. Not only will the new project need to be tested, but regression testing is also important to ensure that new development work hasn't unintentionally impacted other features or sections of the website.
• A project manager or scrum master is often responsible for overseeing and coordinating the project, which can often be taking place alongside the implementation of other projects.

So there is every reason to have clarity in what the project needs to achieve.

Any ambiguity or fuzziness in the requirements is likely to mean that things get overlooked, and that could mean delays, costly re-working, more errors, and potentially impact the launch of other projects which were being worked on within the same release schedule.

What are Test Cases?

Test cases will define the purpose and desired outcome for each scenario, and each step which needs to be carried out to reach the desired outcome.

Pre-conditions and post-conditions will also be defined, so that everyone is clear what needs to be in place before that particular procedure can be carried out, and what is expected to be a successful outcome.

There may be one starting point, but there many possible outcomes depending on factors such as user type, location, age, sex, selections made, etc.

At the heart of this is the user... which in many cases will be the customer. That's where our focus should be.

Why should a website be focused on the customer?

Without customers a business won't survive. Efforts to identify and effectively reach out to the right type of customer can be costly, and if their first point of contact with your company is through your website, you'll want to make it as easy for them as possible, and if possible tailored to their needs.

In other words personalise the experience

Obviously there are things to we can do to achieve this, and also things to avoid doing so we don't lose the potential customers we have worked hard to reach.

Target your language to suit your audience

In many industries, trades or professions, we communicate with each other using in-house terms, jargon, phrases and acronyms. So imagine how lost your potential customers would feel if they arrived on your website and needed to look up the meanings of terms of your trade before they stood any chance of understanding what they were reading.

They simply wouldn’t do it!

Instead you should be communicating to your customers in a way that THEY understand, and so without dumbing it down in a patronising way, any unnecessary technical jargon should be pushed out in favour of everyday language.

Tailoring your website to suit your audience

Who is your target audience, or your ideal customer?

Everyone is a common rookie response, but in most cases you'll need to be more focused in attracting the right type of person. After all, the question was Who is your target audience? and to hit a target we have to focus.

Start by answering these fundamental questions:

• What do your customers need?
• What problems, wants or desires do they have that you can provide a solution to?
• Why have they come to your website?
• Does your website provide what they’re looking for?

Not everyone has the same needs, and people are motivated in different ways, such as by price, quality, reliability, service, prestige, urgency, and so on.

Once you have an understanding of your ideal customer and how you can meet their requirements, creating buyer Personas (or Avatars) can help you to set the scene for them when they arrive at your website.

What are Buyer Personas?

Let’s consider two people with different needs arriving at a car rental website. They both need cars for their holidays, but have different criteria besides when and where they intend to rent a car. So we create scenarios based around typical requirements of each potential customer type, and we make sure that our designs cater for them.

So let's take a look at a couple of buyer or customer persona examples

Buyer Persona Example 1

A guy in his mid 20’s plans to take his fiancé away for a few days, and he wants to impress her by renting a sporty car from the airport as soon as they arrive.

He wants something flashy, and therefore isn’t going to be attracted to the cheapest car available, as the image of them driving along the coast with the roof down with clear blue skies above really appeals to him... and it's bound to impress his fiancé!

Insurance waiver options aren't on his mind at all... He just wants to live the dream, but it still might be to his advantage that he is made aware of the options available to him.

So he visits the car rental website:

• Can he find the car he wants to help make this an exciting and memorable trip?
• He might be so focused on the glamour aspect of the car he wants to rent that he might not be aware of some options (ie insurance) which might be to his benefit.
• Is there any important information which he NEEDS to be made aware of, such as any age restrictions?
• If, as a guy in his mid 20s, he is not quite old enough to rent his dream car, can a suitable alternative be offered to him so he still ends up making a reservation on your website instead of going somewhere else?

Buyer Persona Example 2

A guy in his mid 40’s has booked a holiday in the US in July for himself, his wife, his 2 year old son and 7 year old daughter.

He has searched on Google for cheap car rental in Orlando and found a promotional page for a special deal for 20% off bookings within a certain date range.

He’s on a tight budget, but the cheapest car simply won’t be big enough for all 4 passengers and their luggage, and he also needs two child seats which are suitable for the ages and sizes of each of his children.

A sat nav is important, and he also wants to allow his wife to drive occasionally, and so will need to make sure that his reservation has an additional driver option.

He also wants to know about what could happen if the car breaks down, and if there would be any additional charges if he returns the vehicle early.

So he visits your website and embarks on his own customer journey:

• Can he find the car, features, equipment and information that he needs?
• Can he easily determine which seats (child seat, infant seat or booster seat) he should select for each of his children, and the additional cost these will incur?
• Does the car have a built in sat nav, or will it cost extra?
• Was he clear on the terms and conditions of the discount offer?
• Was he able to apply the discount code for the special offer, and are the prices he sees inclusive of the discount or will this be applied at the end of the booking process? How is this communicated to him?
• What about adding his wife as an additional driver? Will it cost extra, and does the online booking process allow her details to be captured too, including age which might impact their choice of vehicle?
• How can you make his user experience clear and easy enough so he ends up renting the car from you instead of looking elsewhere?

Catering for different buyer personas

We have considered two different visitors to the same car rental website with very different requirements, but the buying process needs to cater for each of those personas, and also many others.

So we need to ensure that their potential needs are captured during the requirements gathering phase, and documented in such a way that when the web development team write the code for each feature or component, the team fully understand:

• what needs to be displayed,
• where and when it needs to be displayed,
• under what conditions,
• and what it is expected to actually do.

Let's continue with the car rental website for a bit longer...

• This is a multi-lingual website, so how do we know what default language to display the website in, and how do we present the customer with the option to change the language?
• How can we tell what country the customer is in, so as to determine things like which currency to display prices in?
• Is the customer a guest or logged in as loyalty scheme member, and what features need to display to each customer type?
• Is a travel agent making a booking on behalf of their customer?
• How should we allow the customer to select where to pick up their rental car? A free text field to search? Dropdown list? Can the search handle common misspellings or translated searches, such as London or Londres?
• How should the pickup and return calendar be displayed, what start date should it default to, and should a default return date and time be pre-selected based on a certain number of days after the selected pickup date?

Handling business requirements

In theory there could be hundreds of very specific requirements written for the entire customer journey, but let’s break things down into their simplest form and determine what in terms of personas they need or expect to see, and under what circumstances.

And when they click this thing or enter some information or make a selection, what should happen then? Will the resulting action be a straight Yes/No, A/B outcome, or will there be a range of possible outcomes based on the input or selections made?

The developers need to know this, as they cannot code based on vague opinions or suggestions. And before the website, page or feature goes live to the public, testing procedures will need to confirm whether each feature is working as designed.

User stories - Keeping it simple

A user story can be used to set out some very easy-to-understand requirements and steps, as well as to define certain pre-conditions and what a successful outcome looks like. It also might need to set out alternative outcomes.

In a nutshell we need to approach them by taking a Who What and Why approach, which could look very much like this:

• As a {persona}
• I want {to see} {to do} {to have}
• so that {I can}

So let's put this into plain English and look at some examples:

• As a parent renting a car in Germany,
• I want to see child seat images displayed with age range and size information,
• so that I can include the correct size child seat with my car rental.

Or...

• As a driver renting a van to move house,
• I want to see cargo capacity for each van with accurate length, height and width dimensions,
• so that I can choose the most appropriate van for my needs.

From within your organisation you might be seeing things such as:

• As a marketing executive,
• I want an interface with the ability to schedule start and end dates for promotional splash pages,
• so that I can automate when promotions become active and expire.

Or...

• As a garage owner,
• I want an interface with selectable hour long time slots,
• so that customers can book their own vehicles in for a service.

If you or your organisation use a project tracking tool such as Jira, it is likely that the format described above will be used within the Issue type: Story

User stories INVEST Model

The purpose of this article is not to provide an overview of the Agile development processes, but to serve as a high level introduction to personas and user stories. However, as there is a set of guidelines which could be followed when creating user stories...

INVEST is a common model for determining user stories are well articulated. INVEST which stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.

Independent

Each user story should be able to be implemented independently, and not need to wait for other stories for the customer to experience the value. Of course there will be some requirements which need to be split (or sliced) into smaller user stories.

Negotiable

User stories should have just enough detail for team members to know what it's about and discuss, and be flexible enough to evolve if necessary.

Valuable

Each user story must provide valuable to the end user, whether it be a customer or team or individual within the organisation.

Estimatable

The user story needs to be clear enough for the team (developers, testers, etc) to be able to estimate the amount of effort required for completion.

Small

If the story is for work which needs to be considered for a sprint, it should be small enough for the team to understand, estimate and complete.

T is for Testable

The story should be clear enough to allow it to be tested from a user perspective and has a good start on acceptance criteria.

Test plans can be closely related to the requirements set out in the story, and might also include additional information such as how a customer using a mobile device will interact with the new requirement or feature, and how a customer using a laptop or desktop computer will interact with it.

Such detail is likely to be covered by the Acceptance Criteria. After all, we need to all be able to agree and understand what Done means!

In conclusion

For some readers the use of personas and user stories might seem like overkill. Maybe too granular, too labourious or even too basic. I'll admit that I had mixed feelings when I was originally introduced to this concept several years ago, but I quickly saw the value of clearly setting out requirements in this way.

However complex or basic your website is, from a single page WordPress site to a 10,000+ page international eCommerce website, you should ALWAYS consider everything about your website from your customer's perspective.

If you need help with writing test cases in line with your business requirements, or with testing during staging or in the live environment, get in touch.

daron@targaweb.com   

01406 373511

Useful Links

The are plenty of in-depth articles out there covering best practices for using persona and writing user stories. My recommendation would be to start with is this piece from Atlassian, and this specific page about Issue types