Updated: Nov 4
Assumptions are made by people who build brilliant businesses alongside people who can program the most intelligent code. Numerous lists of user stories are transformed into long streams of ones and zeros. But there is so much time and effort put in the system, that they forget one little tiny piece of the puzzle... The user.
HOW DOES THIS HAPPEN?
Assumptions are made by people who build brilliant businesses alongside people who can program the most intelligent code. Numerous lists of user stories are transformed into long streams of ones and zeros. But there is so much time and effort put in the system, that they forget one little tiny piece of the puzzle...
FAILURE TO IMPLEMENT USER-CENTERED DESIGN CAN LEAD TO:
users not understanding a system built to serve them
users being frustrated with the functionality of said system, and
the user not using the system and adopting another system (from a competitor)
First the business goals must be crystal clear and transformed into a strategy (with all stakeholders involved). A workshop with all stakeholders works really well. Most importantly, you must engage with the the user, and the sooner, the better.
I’m reminded of one of my university projects. A fictional board of directors wanted a new website. We asked this fictional board, “Well, who are the users?”
And they said, “The students.”
Which is of course very true. But which students? The actual students? First years? Graduates? Alumni? And what about foreign students?
After spending some time investigating, we discovered there were over 35 groups of possible student definitions. And after that, we discovered that we could also investigate which students impacted the business goals the most. We determined that it was not current students who contributed the most towards the success of the overarching goals, but it was the prospects; the aspiring scholars who were not yet students.
What does this tell me? Prospects: male or female, between the age of 15 and 20. That does not tell me too much. After a combination of qualitative and quantitative research and analysis with real human beings, it is possible to translate patterns presented in their data into a story. If the average age of a prospective student is 17, with 61% of the students being female, mainly located in rural areas, let’s get in contact with them. Next, let’s make a thorough questionnaire and then conduct an interview!
Here we go! Meet Sofia. She is from Ramsbury, North Wessex - a small village in the UK. She was raised in the countryside and lives on a farm. She treats all the farm animals as if they were her pets. She has three older brothers who have always worked on the farm. She has her own laptop; however, due to her location, her internet connectivity isn't great. Sofia has always wanted to experience life outside the countryside and wants to experience the city. She dreams of going to a university in London, but she is a little afraid of the unknown... because she has never left the village.
Ok, do you have a mental picture of Sofia now? Can you imagine her needs? Can you imagine what problems are at the forefront of her mind? Below, I include an pdf illustrating what her “persona” might look like. Feel free to use it! The second page is a blank form which you can fill in and use yourself.
HOW TO MAKE A GREAT PERSONA
First, you should base your persona on facts. Look at analytics, have a conversation with the customer service team who manages interaction with prospective students like Sofia. Find out which groups of users you can define. Then, select the most important users, make a questionnaire and have a group session, one on one interviews or a “day in the life of” where you shadow the user.
Once you've elucidated the needs of the real users, try to combine them into a single persona or make a few different personas. Give the persona a catchy moniker and a character that defines the persona (Rick the Rookie, Freddy the Freshman, Gerald the Graduate, etc.)
Give the persona a face. Some people say it must be a photo, but feel free to use whatever works for you. Give the persona a short character description: A short story which explains their history. Their limiting factors. The devices they use. Elaborate on their situation, giving their journey a context.
At WORTH, we use personas to understand users. We utilise them to ensure that developers understand users as well. Furthermore, we use personas to validate application features (for instance in a feature matrix) and to define their perspective within the customer experience (in the form of user journeys/customer journeys). These are continuously updated during the process as customer behaviour evolves. Developing a persona is an excellent means of understanding your users' needs, goals and frustrations and allowing you to design an appropriate experience, whilst communicating that information in a digestible format.