Value of the UX or how to make Personas work
UX for enterprise: case study (part 1).
There is an omnipresent complaint from designers: managers do not see the value of the user experience (UX) design deliverables.
Why?
You could say—because of differences between the manager’s expectations and the real designer's work. We, as designers are making almost impossible things in UX, but ‘they’ do not understand ‘us’.
Sometimes managers measure the quality of the design work in mockups. In difficult cases, by the number of mockups. We are not talking here about such an attitude.
But what if managers do not see the merit of UX design… Because a designer does not properly show the value of his work to the stakeholders?
Or worse — the manager has had an experience of spending a month on the design research, and as a result, got useless digital artifacts?
Every situation has a chance to improve. What about to become a valuable designer?
In this series of articles, I share my experience of applying ‘abstract’ UX design tools to the need of the real product — redesign of an enterprise solution.
I suppose, that you know the basics of the design process, what is Double Diamond, or some similar methodologies. I would not cover these topics because we focus on the deliverables. We’ll talk about:
- how to make useful UX deliverables,
- examples of them in a ‘bloody enterprise’ practice,
- ways to show the value of your work to stakeholders.
Intro: about the author, company, and products
Hello 👋 , my name is Aleksei and I’m working as a senior digital product designer in EPAM Systems. Some know the company for software outsourcing, engineering expertise side. But there is scarce info about the internal products.
In a big software house environment, we, as designers, are working in teams on a vast ecosystem of internal products. EPAM has more than 100 digital internal products, 60 designers, divided into Streams for all business processes—Delivery, People, Finance, Staffing, Media.
Every Stream covers a bunch of the products—from CRMs, databases, HR systems, info portals, digital management tools, to link shortener web app.
So, for the designer, there are plenteous possibilities to explore and create.
Objective
Imagine the situation: you, as an enterprise product designer, are doing guerilla UX research as a team-of-one. You have the freedom to act and limited time for design activities.
Task
Redesign of Vacation portal, a corporate platform for management of all time-off activities (web app, more than 30 countries, thousands active users).
In short: if you need a vacation/other leave, you book it via this portal. Business workflow varies, depending on the country laws.
The remote multidisciplinary team in Belarus, Kazakhstan, and Ukraine.
I was a key designer for this task, Belarus as a starting location for the launch.
The original solution had issues: technical debt, overall logic/usability flaws, outdated UI plus huge support effort.
The product management came to the point: everyone agrees that a new product solution is needed, but nobody knows where to start.
Before jumping in the ocean
At first, you’ve better know your stakeholders, who is responsible for what. This process is a keystone for any effective collaboration, so do not neglect it.
Making kick-off and stakeholders meetings, I have seen huge gaps in the understanding of the product’s users.
An important point for any digital product designer is the knowledge of users.
There are situations where a designer has no direct access to users. Sometimes it happens due to the client security requirements, outsourcing projects, etc.
But we are talking about digital product design, so we suppose that you have the ability to study users — directly or not.
So we are starting with personas.
This method is good for systemizing and presenting information about your users. Reasons to use them:
- They give the team a common design target (for whom do we build the product?).
- They help prioritize audiences and bring a focus on the most important users (why do we choose them?).
- Assistance in prioritization of product requirements (what do users need from the product?).
But often their image is dreaded as an almost sure way to waste time. Why?
Creating personas is a tricky process. Like cooking an egg — a child could do it, but make it delicious… Not everyone.
There is a variety of templates from the Internet, but which one suits your product? At the start, we lack the information to make a useful artifact about our users.
Maybe try proto-personas?
Unlike the personas, proto-personas are based on the assumptions of the stakeholders, and further, they are checked against gathered data.
It is ok if you are an experienced designer and you have a clear understanding of the process, business domain, etc. But often making proto-personas look like this:
A designer who does not know the users tries to get the UX deliverable, chaotically describing users. And reasonably fails.
In an enterprise environment risks are even higher, so we’ll go another way.
A typical process for building personas is the following:
- Define audience by analytics or stakeholders interview.
- Make interviews, field studies, if needed — surveys with selected users.
- Conduct a workshop with a team to aggregate, validate and assess the results.
- Construct the set of personas, refining and validating their attributes.
But there are some situations, where you have difficult design requirements (a lot of objects to analyze and design). And there you need to customize the process.
Below is an example of such customization for our leave management product.
1. Developing the framework
So, before making any artifact, I did research activities, using the method of progressive disclosure.
Step by step you are reducing the amount of unknown, like cleaning an onion. On the workshop with stakeholders we did the following:
- Defined selection criteria. Main question: What do we need first? We used card sorting in Miro for that task. As a result, selected priorities: the primary region, the number, and type of requests.
Example: Belarus, average requests per year—25, leave requests.
- Continued to User groups (UG). Whom do we need? UG are chunks of users, ranged according to their positions and duties in the company.
Example: Employee, Manager, HR, Support, Accountant —who is a person in a company.
- Selecting Roles: action flows of UG in service, amount of their power.
Example: End user (2 subtypes — experienced and newbie), Approver, Operator, Admin —what are permissions in the service.
- Describing Jobs — core detailed functions that the user does in the service.
Example: Booking a leave, approval of a submitted leave, etc.—what exactly a person does in the service, according to his UG and Role.
Why bother with a framework?
Remember, we got more than 30 countries. The workflow varies, Roles and Jobs in different countries are not the same.
If you use traditional personas, you lack flexibility. Developing a specific approach to every country is time-consuming and expensive.
But the framework gives you the freedom to customize your future personas. Basics are the same, you could change them for the need of business.
Examples:
In Belarus, Manager (UG) as an Approver (Role) gives company approval (Job) for the leave request by his teammate. The same Manager (UG) as an experienced End-user (Role) submits a sick leave for himself (Job).
In Switzerland, HR (UG) as an Approver (Role) gives company approval (Job) for the leave request by an Employee.
As you see, we can easily mix ‘Lego blocks’—User Groups, Roles and Jobs, gaining necessary flexibility.
2. Meeting the users
Now we know basic elements:
a. who are our users (by their roles in the portal),
b. what and why they do in the service.
But we do not know Users closely. Their problems and emotions in the service are not covered.
So, we narrow the unknown further: go to the people, our employees.
At this stage, we already had some assumptions, so initial validation needed.
As the next step, I made usability testing sessions of the current solution with users. Basic flows for booking a typical leave, short sessions.
I didn’t conduct full-scale interviews. Why? The user isn’t thinking about the service constantly but he knew that the old design is awful. Better not to ask, but watch the user’s behavior and see the real problems.
In moderated usability testing, we had opportunities to communicate with users. Not only ask about opinions but listening to them, watching their actions. The less you talk, the more information you get.
When the user shows you his workflow, his commentaries are immediately validated.
Also, to understand the problems of our users, I worked closely with our Support team. Usually, these guys have plenty of useful insights.
3. Crafting the attributes
We have gathered the necessary data for our Personas.
In a workshop, we did prioritization for the attributes and selected the following:
Basics
- Name, Photo, UG, Position (title).
- Story (context), and short Quote from usability testing, such as “The most important thing to me (in the context of the service)”. Without a biography, brand preferences, and other marketing mumbo-jumbo.
Heuristics
Indicators, affecting the speed of work, behavior, knowledge of the service, factors influencing users, etc. Without them, it is difficult to differentiate users.
- Familiarity with the service;
- desire to know the service;
- time in a company;
- level of stress at work;
- how often a person uses the service.
Example: an End-user who works in a company for 4 years and uses the service several times a year (without any desire to know it deeper) ≠ a newbie End-user who needs to use the service 10 times a month due to his life circumstances. What do they value in the service? What factors are affecting their experience?
Role(s), Jobs and Specific actions
- Role—action flows of User groups in service, amount of power.
- Jobs—core detailed functions which User does in the service.
- Specific actions mean distinct jobs that are done by a persona in service.
If our user is not doing anything special in the service, this section is marked ‘According to the Role’.
Example for specific action: End-user uses the service to see the information in the Calendar tab. A Calendar is a separate tool that is integrated into our solution (an excessive feature).
Specific actions were needed to eliminate excessive functionality, giving place to essential features.
Goals, Feels, Wants, and Pain Points
Aims, overall attitude, and emotional markers of the service.
Proto Value proposition (PVP)
We knew, that our users, employees, must use our service in the company.
But as for the product team goal, what real value we could offer to them?
PVP is a statement that will show our proto value offer to the User.
At this stage, we only sketch the offer as an assumption. The work on the Value proposition canvas will be highlighted in the next article.
Now we are ready to assemble our Persona. Below is a real template from the product UX knowledge base.
4. Making personas
We add the muscles to the bones, make our artifacts living entities.
Sure, it’s teamwork. Every stakeholder was involved in the developing process, so they understood the value of personas for the product. Moreover, this work was the starting point for establishing the whole design process.
Initially, we have got 9 personas, covering all users.
Backed by the user research data, on a workshop with a team, we prioritized the circle of essential personas.
In the end, we have had 4 personas. In short (who, name–main functions):
1) Usual employee, Victor — quickly report the time-off,
2) Manager, Vladimir—effectively work with the absences of the employees on various levels,
3) Admin, Yunona—establish rules and set up the stage for all the time-off process,
4) Operator, Hanna—custom-crafted persona, could be admin and manager (or have a part of their functionality).
Now we know the main actors and what is important for them.
I continued work with users, made series of the interviews, to validate our personas and know prioritized users better.
5. Showing the value and selling the result to the team
After all, if you involved teammates in the personas' work, the result will be appreciated by the team.
In my case, final personas were presented on the special demo session and were approved by the whole team, aligning efforts. This allowed us to move forward in product development.
Here you can see: artifacts for the Personas are secondary.
During the process of their constructing a designer gets information about users, validates it. This is the most important, and artefact are only supporting this knowledge.
What’s next?
As you’ll see, personas are needed to continue the design work, going through the whole process.
In the next articles, we’ll find out how to build other useful UX deliverables: the Value Proposition Canvas, Problem statement, Hypotheses, CJMs, Flows, and Information architecture. At the end of the journey, we will look to the result.
Thank you for your attention and feel free to connect with me on LinkedIn.
