Platform Personas

Beginning to define our user base

Company
Lifion by ADP
Project Date
June - July 2019
ROLE/TEAM
Product Designer (myself), 1 UX Manager, 2 Dept Heads

Lifion is a low code platform that enables users to build complex HR applications without the need of writing code.

When I joined the platform team, my first project was to do some exploratory research to create a partial picture of who our users were. Since this was the first planned phase of many, we decided to limit this to our core users. I.E. developers who use our platform.

The Goals

For the Company

1. Up until this point, the company was so focused on building a product that worked, they hadn’t been considering how well it worked for its users. However, once that proof of concept existed, the only way to continue to grow as a company was to start paying attention to users and that needed to start by understanding who those users were.

So the goal for them was to define the key personas for our overall platform product, which could then help steer the direction of where we took our work moving forward.

For me (Design)

1. Create a range of user personas for multiple experience levels.

2. Show those users journeys from one level to the next.

3. Use research methods to ensure accuracy.

Research Phase

To get started, I met with my stakeholders and understood from them that experience level was a key factor in this process. So I went out to find 7 users from vastly different teams. I made sure I had 3 who were new to the product, 2 who were very familiar with it, and 2 in the middle. 

Met with some People

I then created this script to get a sense of where they were in their journeys. I crafted questions that would both reveal information about our users, without directly asking for that info so as not to skew the results.

One example was "how long was it before you could complete a Jira ticket with minimal help?" This allowed me to start quantifying the time lines for when a user would be at what level. The average answer would be the key.

Part of my preparation for 1:1 user interviews is to make an interview script with all my questions. I prefer spreadsheets so notes can be tracked easily across all participants.

What Users said about Onboarding

New Users - Materials Unhelpful

Newer users found the training materials were not keeping up with the pace of change within the concepts they were explaining. In other-words, videos and articles were out of date and moved too fast past important points.

Intermediate - Teammates are a Safety Net

For mid level users who had already realized the training materials sucked, relying on teammates knowledge was key. However, there weren't guarantees someone would be around or have bandwidth to answer blocking questions. So this strategy posed risks.

Advanced - Loop us IN!

One advanced user told me that when he needed to solve a problem, he found a workaround. That workaround ended up being due to a bug that the platform teams eventually fixed. Breaking his solution. If he had known that beforehand, he could have planned better. He was asking for more transparency since he saw himself as a leader.

Building Personas

After speaking with users in depth and asking questions about their processes, I was then able to create 3 distinct personas. Separated by a rough estimate of level and how long they'd been developing on our platform.

Also, I want to note that we didn’t have anything like this before, so I had to take it upon myself to create the visual language and artifacts from scratch to convey this information.

New Users - 3 months or Less

All the information here was extracted and amalgamated from the interviews I did with all the users (not just the newer ones). After all, everyone was new at some point.

Intermediate Users - 7 months to a Year

For this persona, I extracted information from both mid levels and advanced users. 

Advanced Users - 2 Years Experience

For this persona, I only took from the advanced interviews. Since that was only a few people, I went back over this with a larger number of advanced users to make sure I was capturing things accurately.

Adding Experience Maps

Once I had the personas in a good place, I began to create assets that could map those personas onto how they moved through both task completion and learning how to use the platform to begin with.

All Users - Learning Methods in a Usage Map

This map was created to show the evolution of a user and what methods they use when they got stuck in using our platform. You can see that as a user matures, they become more independent and bold in how they resolve their issues. This was all compiled from answers to questions I asked in the interviews and then validated by a bigger user base before completing the documentation.

New Users - From Onboarding to Working Independently

For this persona, it was important to capture what it was like to get comfortable using the platform in order to figure out how our team could better equip them for a smoother onboarding process.

Intermediate Users - From Completion of First Story to More Complex Work

Here I was more focused on identifying the "WHAT" of the increasing complexity of the user's work. This work had a big impact on our Lifion Branch Management tool since versioning was considered a more complex task.

Advanced Users - From Continuous Learning to Becoming a Leader

For advanced users, their journey began with their process for learning new features on the platform and ended with them becoming a teacher and mentor to other, newer users.

Outcomes

1. Since completing this work, my entire team has been able to leverage the personas when solving design problems. A big example of this is there are often times where we need to create complex flows and finding the right balance of instructional help (tool tips, wizards, etc) without adding too much for those that may be more seasoned platform users is tough. The personas help us in navigating these challenging areas.

2. Another big takeaway was just how frustrated newer users seemed to be with the current state of training materials. So following this persona project, I went through and redesigned our training website.

1. Due to some issues on the back-end, engineering and product had to add an extra step called “Submit”. In testing, users found this step confusing since it was styled the same as “Create”. 

2. For the DC Provider project, I heard from all user types they wanted the flow to be unified and have consistent patterns. In order to do that, I needed to consider all the different types of uses who would use it. This is where the Persona's came into play.

3. The screen shown here is mostly automated for users, with a bunch of text and tool tips that explain certain aspects of the page. It's made to be easy for newer people to use once they have a small amount of knowledge of our platform.

4. However, this screen is for more advanced users. Though this is just another option in the same dropdown/flow as what is shown above, it's a more advanced form of provider configuration. By creating a flexible design that works for all types of users, I considered the personas by how I unified all elements of this project. For further reading, see DC Provider case study.

1. Understanding that newer users would rely the most on this documentation, I created designs that devoted a lot of space on the first lesson a user would engage with and less as you scrolled down the page.

2. For the DC Provider project, I heard from all user types they wanted the flow to be unified and have consistent patterns. In order to do that, I needed to consider all the different types of uses who would use it. This is where the Persona's came into play.

3. The screen shown here is mostly automated for users, with a bunch of text and tool tips that explain certain aspects of the page. It's made to be easy for newer people to use once they have a small amount of knowledge of our platform.

4. However, this screen is for more advanced users. Though this is just another option in the same dropdown/flow as what is shown above, it's a more advanced form of provider configuration. By creating a flexible design that works for all types of users, I considered the personas by how I unified all elements of this project. For further reading, see DC Provider case study.

Takeaways

1. Following this work, I pushed hard for a more comprehensive overhaul of our training program as well as the community we needed to build in order to troubleshoot problems. Higher ups were hesitant to invest time in these resources since they wouldn't have immediate revenue impact. In the future I would spend more time on pitching the long-term benefits of a training program overhaul, rather than focusing on creating the assets.