Customers, Personas & User Stories

Not every customer is like you!

Not all customers are like you!

Different customers have different needs...

Make sure you're aware of those differences and design for them.

Be aware of the needs of different types of customers, and cater for those needs.

Customers, Personas & User Stories

The need for focus & communication

After I had been working in eCommerce for a large multinational corporation for 15+ years, we embarked on a hugely expensive and very intense digital transformation, involving dozens of people in various teams from the UK, US, Europe, Canada, etc.

There were project managers, product owners, scrum masters, business analysts, content writers, marketing experts, UX specialists, and of course there were web developers and people responsible for testing.

There were also teams who worked on a number of back end systems, and all of this work needed to be co-ordinated and managed against succession of timelines, because not everything could be done at once. Some things needed to be completed in a specific order, because X needed to be completed before Y would work, and Z couldn't even be started until Y was working and A, B and D were also in place.

Precisely agreeing on the requirements and communicating them to all parties involved with this digital transformation was no easy task.


Bite size chunks are easier to digest

The website was just a piece of this project, because the back end involved systems to support products, services, costs and availability, and this would determine what the website displayed. And of course selections that the customers made on the website would be fed into to the backend systems to allow things to be added to the shopping basket, enable transactions to be made, and allocate the items to the person who had just made the purchase.

By breaking this mammoth project into small manageable chunks allowed it to be sliced into tasks and objectives, and each of these needed to be clearly defined so that:

  • The person responsible for each requirement being captured can define what a successful outcome would be.
  • The web developers responsible for writing the code to implement each requirement have a clearly defined goal to work towards.
  • 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.
  • Those responsible for testing each piece can write test cases based on the original requirements and be able to 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.

Okay. Lots of talk so far, and no mention of customer focus, personas or user cases. So let’s get to it...

[Back to top]


Why should a website be focused on the customer?

I would expect that in most industries, trades or professions, we communicate with each other using in-house terms, jargon, phrases and acronyms.

We understand what they mean within our profession or organisation, but if you’re new you might quickly realise that you’re going to have to learn this new language in order to understand what the heck your colleagues are talking about!

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. They simply wouldn’t do it!

No... you should be communicating to your customers in a way that THEY understand.

[Back to top]


Target your language to suit your audience

So without dumbing it down in a patronising way, any technical jargon should be pushed out in favour of everyday language.

But besides language, what do your customers need? Why have they come to your website? What search term did they put into Google before they found your website, and does your website match what they’re looking for?

  • People might need an electrician, but what they might really need is an electrical inspection for a property they're letting. So talk in terms of electrical inspections for landlords and not exclusively using terms and abbreviations like EICRs.
  • People might need an accountant, but what they really need is help with their annual self assessment forms. So communicate that in a jargon-free way.

So you should be thinking in terms of what your customers need, and provide a means for them to find what they’re looking for on your website. If they can’t, they’ll go somewhere else.

[Back to top]


What are 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 potential customer, and we make sure that our designs cater for them.

Customers, Personas & User Stories

Persona Example 1

A guy in his mid 20’s plans to take his fiancé away for a few days might want 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 is bound to impress his fiancé!

He isn’t particularly interested in the insurance options, because that’s not on his mind... He just wants to live the dream and doesn't want to think about additional insurance cover, but it still might be to his advantage that he is made aware of the options.

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 focussed 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 instead of going somewhere else?

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 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?
  • Does the car have a built in sat nav, or will it cost extra?
  • Was he clear on the terms and conditions of the special offer?
  • Was he able to apply the discount code for the special offer, and are the prices he now 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 he need to provide her details too?
  • How could you have made it clearer to him so he ended up renting his car from you?

[Back to top]


Catering for different personas

So two different visitors to the same car rental website with very different requirements, but the buying process needs to cater for these personas, and many others. Also note that personas can equally apply to people within your organisation and not only customers.

How can we ensure that their potential needs are captured during the requirements gathering phase, and documented in such a way that when the web development team need to write the code for each feature or component, they are clear on what needs to be displayed, where and when it needs to be displayed, and under what conditions.

Customers, Personas & User Stories

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, 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?
  • How should we allow the customer to select where to pick up their rental car? Text field to search? Dropdown list?
  • 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?

[Back to top]


How can we tell whether we're getting it right?

Well you're a customer, right? You might not be a customer to your own business, but you're a customer to another business... many other businesses.

When you buy or engage with these other businesses, whether it's online, in store, at an event, etc., you'll know whether you're happy with the experience. If you weren't entirely happy for any reason, you might not have made a purchase. What if the owner of that business is willing to hear why you didn’t buy, by getting some honest feedback?

Well in the real world, unless a someone is so unhappy about something that they're actually driven to complain about it, businesses don't tend to hear about things that their customers would prefer to see. This might be feedback such as:

  • having a range of products displayed in a different way, or
  • having specific information available in the right place at the right time, or
  • having clearer pricing, or
  • ???

The list could be endless, but our customers (or potential customers) are the best people to tell us.

So let's use our knowledge of customers... different types of customers... and base some personas on them. We design our process around those personas, and we test.

User testing is a really important way of telling us whether we have designed and created what our customers want. If we have, the feedback should reflect that. If we haven't, the feedback should reflect that too, and tell us why.

That's when we collate that feedback and do something about it.

So let's define what we need to design for. Let's get specific, but keep it simple...

[Back to top]


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 who (persona) needs or expects to see what, 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 options based on the input?

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 simple 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.

They follow a fairly basic format, such as:

  • 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 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 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 for a service

[Back to top]


In conclusion

For some readers this 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 my scepticism was unfounded, and I quickly saw the value of setting out requirements in this way.

At the very least it should serve to emphasise that what your customers need from you and your business should be made available to them on your website.

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

The are plenty of in-depth articles out there covering best practices for using persona and writing user stories. My recommendation to start with is this piece from Atlassian.


Other Web Design Posts


Daron Harvey, motor racing fan and owner of Targa Web Services

About the author: Having begun building websites back in 1996, Daron Harvey has been professionally involved in website design, UX and eCommerce best practices for over 26 years, including management of large multi-lingual global websites. Following the global pandemic Daron founded Targa Web Services, specialising in Website Design, Search Engine Optimisation, User Experience (UX/UI), etc.
    

Customers, Personas & User Stories Customers, Personas & User Stories
01406 373511 info@targaweb.com