One global retail corporation that recently acquired a national competitor needed to design and build a custom workflow software application for new personnel. The application is used by their staff of maintenance technicians responsible for supporting the operations of hundreds of retail stores throughout the United States.
While working on-site for kick-off, the entire team collaborated with our Product Owner to plan and map out features and priorities for upcoming sprints.
A slide I presented during a demo to executive stakeholders explaining how user research helps to reduce risk and guide decisions by designing and building the “right thing.”
Over the course of three days, the product team leaders met with the client’s stakeholders and technical group on site to discuss the existing application, new product to be developed, and plan increments for the work to be completed. Discussions examined how operations could be consolidated for the existing business users and those from the acquisition, how we might minimize the amount of training required for a new app, and what third-party frameworks and tools might our engineers leverage as part of the development lifecycle.
During the discovery sessions, our team gathered a solid understanding of how technicians perform their job and what the business needs to measure and have visibility into as part of the system.
As part of increment planning, our team helped the Product Owner organize proposed features and functionality into a preliminary increment planning board based on the first round of the product timeline.
Topic discussions included:
After my contextual inquiry with a technician working in the field, this was the summary slide I presented to our executive stakeholders as I began working on the user journey map.
I spent an entire workday with an experienced maintenance technician in my area to learn how they do their jobs to design an app that matches how they work. After capturing 13 pages of hand-written notes, I added the most key details and information into a user journey map and presented it to our team and executive stakeholders.
After project kickoff, one of the very first activities we performed was a contextual inquiry. I spent an entire workday with an experienced maintenance technician in my area. The Product Owner and Technical Lead each shadowed a technician in their areas also, giving us insight into how three different techs do their jobs in three different states.
Conducting a contextual inquiry as part of my user research was the most helpful, eye-opening activity.
As a UX Designer I didn’t know what it’s like to work as a maintenance technician. So, one hot summer day, I woke up at 5:30 AM to get ready and drive over an hour away to meet with a local tech before 8:00 AM to observe his work day from start to finish. I truly got to see it all—from the small victories to stressful moments, working indoors and outdoors, maintaining different types of equipment, updating truck inventory, and taking several different driving routes.
Throughout the technician’s eight hour work day, I captured thirteen pages of handwritten notes and nearly one-hundred photos. Upon returning, I met with the Product Owner and Technical Lead to learn about their experiences in the field and share information.
Creating a user journey map and the personas below were instrumental in providing context to our development team who did not have store locations near them. As a designer, watching how a technician worked and speaking to them about their jobs firsthand guided every design decision that I made. I believe this was the best, most impactful design activity I did with the time and resources that were available to me.
This user journey map is an outstanding document, very well done Jamie. Nice work! Great document. I especially love how the tech took the time to teach the store personnel how to resolve the frappe issue on their own next time. Nice touch.
Experienced maintenance technicians have been working at their job for awhile and are complete masters at prioritization, time management, planning, in addition to taking care of equipment for maximim lifetime value.
New maintenance technicians haven’t worked for the company for very long, but likely have past experience in maintaining equipment and performing repairs. New technicians are still learning about the business and how to manage their routes.
Regional trainers are those who train new technicians on the job. This persona was once a maintenance technician themselves, and are instrumental in a new technician’s workplace experience as well as mentors to those they’ve worked with for awhile.
Store managers do not use the application but are directly impacted by the technician’s experience using it. I met and spoke with several store managers and realized their experience is incredibly important because the technician is supporting their location.
Area Facilities Managers are the technician’s middle-man and the go-to person for Operations, managing up to 10 technicians. If there is a problem they need quick visibility into what’s going on in the field so they can act quickly.
After conducting a contextual inquiry, I began writing two different technician user personas based on the firsthand conversations and experiences I had with the technician I met as well as conversations with additional technicians.
As part of an Agile product, I continued to update the personas after learning new insights through continued research and testing. The Regional Manager Trainer persona was written with information gleaned from ongoing conversations and work sessions.
One persona I discovered was the Store Manager, a person who does not use the application but is directly impacted by the technician’s experience using it. During my contextual inquiry, I met and spoke with several store managers and realized their experience is incredibly important because the technician is ultimately supporting them and their store staff.
The user personas include:
As part of the team’s Agile iterative design and development process, I created a persona canvas to use during user conversations as part of initial discovery.
These artifacts in addition to the user journey map above were immensely helpful in giving the product team context into who we were building for, their pain points, and what they require out of a new software solution.
Zoomed-out view of the wireflow I created to collaborate with our product team on each design story to create the smallest piece of functionality possible.
After learning requirements for user stories, I created a wireflow with the product team showing how could work. After iterations it was put into the prototype for usability testing.
Screenshot of just one small section of the user flow, pictured for part of the Work Orders section.
This custom mobile software application was designed and developed using Agile methodology. Throughout each sprint, the Product Owner and myself participated in stakeholder conversations and various work sessions with our business stakeholders and subject matter experts. These meetings were critical in understanding the context, business requirements, and workflows that needed to be designed and developed in the system.
As new requirements were uncovered, our Product Owner composed user stories and prioritized features for our team in the backlog. Sprint by sprint, I went through these stories, drew preliminary sketches on paper, and created draft wireflows with our Product Owner and development team, iterating on ideas and figuring out the best approach for development within the ServiceNow platform and Bootstrap framework.
Throughout the software development lifecycle, our team organized all user stories in ServiceNow. To keep the UX work organized, I set up a Lucid board for each sprint detailing the stories to be worked on and the design plans for those two weeks.
After collaborating with the team on the wireflow, I quickly made the newest iterations to the interactive wireframe prototype for usability testing and feedback with users, described below.
One of the most valuable features we built was a QR code scanner for quickly adding equipment into the system. Someday, the engineers can use this functionality to build a scanner to manage part inventory as well. It can take one technician many minutes to manually input data on their smartphone. With the QR code scanner, technicians save hundreds of hours on data entry across the workforce each year.
By creating an interactive prototype in Axure, I was able to get rapid insights from users through usability testing on their mobile devices.
After collaborating on the latest wireflow updates with the team, I added and published the latest features and functionality into a new iteration in the interactive wireframe prototype and linked the pages to the user stories.
Created using Axure, the prototype is clickable and realistically depicts the application for usability testing and gathering feedback from real technicians using their mobile device.
Being an Agile product, the prototype evolved and took shape over time to learn how users:
I utilized the tool UX Tweak as a method to conduct unmoderated usability testing. Users were sent a series of questions and tasks to try using the interactive wireframe prototype.
One of many screens in a cumulative usability testing report for our product team with leadership visibility. This screenshot shows tasks and summary for Part Inventory usability testing.
Pre-study questions were included with each usability test to gather ongoing insights and information about technician’s jobs. This information supplemented the personas and brought ideas for future consideration by the product team and leadership.
Post-study questions were included with each usability testing session. Questions were related to the current Agile Epic work in progress. All included the opportunity for open feedback and subjective rating scale on how difficult they perceived the tasks.
A script of questions were written and organized by section for usability testing. Pictured above are three tasks for the Scheduling section of the application. After watching video playback and assessing task performance, time on task was recorded as well as points for future consideration among the product team and leadership.
After the usability testing tasks, follow-up questions were asked to users to learn more about how they perceived the information they interacted with and what they saw in the prototype as another way to learn about the users and make improvements to the design that match the way they work on their device.
Once the updates were published to the interactive prototype, I wrote a series of usability testing tasks and feedback questions to send to users. For each study I also included a few questions before and after the tasks to gather additional information about the technicians, how they perform their work, what they think of the interface, and how easy or difficult they perceived the tasks to be.
Each sprint, I recorded information for every study into a spreadsheet and cataloged:
Utilizing the tool UX Tweak, I set up usability testing studies and invited a pool of users to participate each sprint at their convenience. I love to do usability testing in person or remotely in a live setting, but with users being across the country and concerns about Covid as time went on, the unmoderated usability testing method was perfect. This way I could understand insights that were needed to reduce risk, improve the design, help guide strategy, support feature prioritization, and contribute to building a high-quality backlog.
As users completed their testing studies, I continually updated the spreadsheet and met with our Product Owner regularly to review the information learned and highlight some areas for further information discussions with the business and additional story writing for the backlog. Some users called me on the phone to discuss their experiences using the existing app and provide thoughts on the prototype.
The client’s business process manager and our Product Owner also continuously gathered the feedback they were hearing in the training sessions that were conducted after each release.
All of this feedback combined contributed to making the product the best it could be, and drove our long-term goal of eliminating the amount of training necessary.
As the team approached Sprint #17, I went through the product backlog and created a visualization for our stakeholders to show the work that we’d completed so far, what we should work on next to benefit users based on current understanding, what is in-progress, and the opportunties we see in the future. Some hightlights:
Task Success Rate
Average/Total Number of Tasks
How Users Perceive Ease of Use
1 = Extremely Easy, 10 = Extremely Difficult
The component library evolved over time, using Bootstrap front-end framework.
The Grid and Spacing section provides a visual reference for all page structures.
The Visual section includes specifications for the color palette, typography, and logo.
Forms make up a large part of the maintenance application. This section details all types of fields, buttons, and related modal windows.
While working in tandem on the interactive wireframe prototype, I built a UI design component library for our developers. Over time, the library evolved along with the prototype. Built in Axure, our developers were able to inspect each of the components to pull CSS styling directly from their browser.
The library outlines the foundational mobile design elements and components utilized through the application, developed with the Bootstrap front-end framework, ServiceNow, and Nuvolo. Someday, the library could be expanded upon and evolve into a design system that supports the design of additional products beyond this application.
The component library was organized into eight sections, likely to expand over time:
The UI design uses the corporation’s existing branding for the overall styling of the application. As an enterprise application heavily based on forms and viewing data, the design is clear, concise, and feels high-end without introducing unnecessary distractions or a lot of page elements that would impact page performance.
This video shows a UI prototype of the design built using Axure. This sample UI supplemented the design library for developers working on the components as a visual reference.
What you helped us accomplish is nothing short of amazing. Thank you for diving headfirst into our business, for bringing visions and hundreds of Post-it Notes to life in an incredibly valuable way, for constant support, and for continuing to advocate for our users. While everyone on the team is phenomenal, I wanted to be sure to give special thanks to [Product Owner], [Technical Lead], and Jamie. This release is a direct representation of your hard work, your care, and your talent. You should all be proud of yourself, but now the real fun begins!
Thank you, Jamie, for your dedication to doing the right thing for our techs and for your incredible work on our portal design. Thank you for always being the bright sunshine in every room—you make us all better.