UX practices

Overview

Beyond understanding who your users are, you should also understand how they interact with the process that you are creating an application to support. Take time to observe your users working with the current solution (even if it is an offline solution) and look for consistent behaviors. Try to look for both moments of friction and moments of flow to identify areas to improve and interactions to maintain.

If your curious where these methods fit into your ServiceNow implementation plan, take a look at the success packs on Now Create

Defining your users with personas

Personas are a UX concept used to create fictional characters to represent logical groupings of users that may use your solution. A persona encapsulates the goals, needs, experiences, and behaviors into a memorable container to guide experience decisions for your solution design. Ideally, personas are developed via user research and synthesis to most accurately represent the population of users that will encounter your solution. In reality, key stakeholders can provide great insights into user groups they represent to create personas for your project.

Create personas for your project

Work with UX experts

If you have the time and access, engage with an in-house user experience team, a UX agency, or your implementation partner’s UX practice to conduct user research and persona workshops to define research-validated personas. For more tactical projects, or when time and ability don’t allow research, consider using a stakeholder-driven persona workshop. Here is a rough outline of that workshop.

Run your own workshop

Gather key project stakeholders together in room with a persona template, permanent markers, and sticky notes.

1. Present any existing research and data you have on your users. All workshop participants should take notes on any patterns they hear in the research presented.
2. Individually, participants will write down all the roles expected to interact with this solution. Consider the notes taken in step #1 and any other insights you have. (3 minutes)
3. Each participant will read their sticky notes aloud. Hand them to the facilitator to organize on a white board
4. Participants will use voting dots (6) to identify the most important roles to this solution. They can vote multiple times on the same role.
5. Break out into groups of 3-4 participants.
6. Each group should select 1 of the top voted roles and identify 1 or more personas that represent that role
7. As a group, complete an Empathy Map for each of the personas (10 minutes)
8. Each group will present the maps they created and the facilitator will organize them on the whiteboard
9. Create new groups of 3-4 people. One way to do this is to have 1 person from each group rotate over to a different group. If you have 4 person groups, repeat this one more time.
10. From the whiteboard, select a role and the related set of empathy maps and try to complete a persona template for each persona (20 minutes)
11. Present the personas back to the room.

A story from the field

ServiceNow’s Workflow Design Studio engaged with a state foster care agency to design a solution for managing the key steps for foster parents, medical professionals, and social workers after a child is placed in a new home. In the world of foster care, it is mandatory that child sees a doctor for specific assessment within 72-hours of a new placement. Foster families have the ability to see any licensed doctor in the state, even ones not employed or trained by the agency. With limited ability to train the doctors or even know which doctor a foster child might encounter, it was critical to understand the possible personas that might interact with the state and how that might shape the solution

Federal funding for the foster care program was tied to getting the doctor’s report within a certain time period after the visit. Creating a solution that reduced the friction for doctors would increase the likelihood of submission and ensure the program was well funded to serve the foster children.

While doing research with actual doctors across the state, the team came to the understand the technical skills, time available, and focus the doctor would dedicate to this process. The insights gathered steered the team towards specific design decisions to accommodate the persona. It was a mobile-first approach that reduced the burden on the doctor to know where to go and what non-medical information they need to provide. Later, when the team conducted user validation with doctors they expressed confidence they would be able to use the solution and delight at how easy the experience would be.

Understand user behavior through contextual inquiry

Contextual inquiry is a method to understand how your users currently behave by directly observing them completing the tasks your application will support. Your observations can include the order of operations they follow, the friction in the process created by the current experience, and the shortcuts they take to be more efficient. After observing a representative group of users, patterns will emerge that you can factor into your solution.

Conduct the observations

Identify a group of participants that you can observe individually for at least sixty minutes. These participants should represent key user profiles of the solution you are building. If you don’t know the profiles yet, consider developing personas before this activity. Define the key task(s) you want to observe during the study. ideally, you can schedule observations during the participants work day and observe real activities, rather than simulate the work. Write down any specific questions you have for the participants and list out any specific behaviors you want to observe. Conduct each observation, taking notes about the software they use, friction they encounter, and shortcuts they take. If you have an additional observer available, ask them to take notes as well. After completing all of the sessions, analyze your notes and identify common behaviors, reoccurring friction, and any inspiration the sessions may have created.

A story from the field

A team conducted this activity for an auto insurance customer that had launched a new quoting application but seen a drop in average call handle time (AHT). By spending a day in one of their sales centers. After spending a full day sitting with the call center agent (wearing a listen–only pair of headphones), one key theme stood out. The current application collected the caller’s information, than a list of the vehicles owned by the household, and then finally asked about any additional drivers in the home. This flow did not match the natural conversation flow the representative had with a customer. To work around the poorly structured user interface, the representatives had a natural conversation (caller information, other drivers, vehicles) but took notes outside of the application. They entered the info into the application once the conversation took a natural break, asking the caller to “just wait one moment, while I get your quote.”

Not only did this process take longer than it needed, but it also created a privacy risk for the company as the caller’s personally identifiable information was written down on paper, or in unsecured applications. This resulted in longer AHT, a key metric for the sales center and a financial risk due to the privacy issue. If they had conducted this study before designing the new application, they would of seen how the calls flowed and designed the interface accordingly.

Validating solutions with user feedback

Getting user feedback early and often pays dividends for the adoption and success of your solutions. Beyond identifying user experience issues that may impact user success, it creates change champions out of the participants. By creating a moment for actual users to feel heard and then respond to their feedback, they feel empowered to support your solution.

One way to solicit user feedback in a structured manner is by conducting usability studies. This method allows stakeholders to observe actual users completing tasks in a prototype or implemented solution and identify areas of friction

Conducting a usability study

In a usability studies, a facilitator conducts multiple one on one sessions with participants representing the solution’s users. In each session, the facilitator asks the participant to complete a series of tasks in the solution while observing their interactions. The focus of the session is on testing the system, not the participant’s skill.

Usability studies should be conducted through the implementation lifecycle of a solution. At the start of a project, you can study the existing solution to establish a performance baseline. As the project progresses you can study increasing fidelities of the solution; from a Figma prototype, to an under-development implementation, and finally to the solution in production.

To run a usability study, you should following the following steps:

1. Prepare for the test by drafting a Facilitator’s Guide that helps the facilitator introduce the study and present the tasks
2. Pilot the test with at least 1 person to ensure the tasks are clear and the prototype does not have any functional bugs.
3. Work with stakeholders to recruit at least 5 participants for the initial round of testing.
4. When the test begins, remind the participant that this is a test of the system, not the user so there are no wrong answers. Your goal is to get them talking aloud, describing what they are doing.
5. During each session, the observer documents issues, behaviors, and any other insights that may help improve the overall experience.
6. After all sessions are complete, aggregate the notes to see what issues were most common across the participants
7. Prioritize the issues based on frequency of occurrence and impact to task success.

A story from the field

Returning to the auto insurance customer, there was a project to update the quoting workflow to account for scenarios where the policy either had more drivers than vehicles or more vehicles than drivers. Some states require the insurance policy to document a primary driver for each vehicle. The project was kicked off because the customer saw a high drop-off rate on the page where this information was collected.

The team created a new concept for collecting this information and recruited potential customers that fit the criteria (more drivers than vehicles or vice-versa). In the initial concept, the user had to select the vehicle name for each driver, but the dropdown only showed the vehicle make and model (not the year). Study participants encountered two issues with this design: Some households own two different model years of the same make of vehicle If they had more vehicles than drivers (say 3 cars, 2 drivers), how do they assign the third vehicle?

Based on these observations a few changes were made to the design: Display the vehicle year and a few digits of the vehicle identification number Change the design to ask the user to pick the user for each vehicle (instead of pick the vehicle). This supports both scenarios because a vehicle needs a primary driver, but a driver doesn’t need to be primary on a vehicle.

In the proceeding round of studies, participants passed this step in the process with no friction and the team committed to role out this change.