Project Overview
Atlas was created in 2018 for technicians at AT&T to access and work on installation and repair jobs - with this app, technicians can view information regarding a job, customer, equipment, etc. The techs play a crucial role as they’re involved in the research, design, development, and testing processes. I will solely focus on one of the features I worked on from research to design to prototyping to handoff to the UI team. This feature is called the OSSLog View and it is a very important system that provides history and circuit information about a job.
The Problem
The OSSLog contains system test results, technician notes, and circuit information, but it exists as an independent platform and techs have to exit Atlas to be able to access it which can get a little annoying. The goal of this feature was to integrate it completely into Atlas so techs wouldn’t need to leave Atlas.
Role
UX Researcher and UX Designer - partnered with another researcher
Responsibilities
- Led user interviews, sent out surveys, and conducted usability testing to learn about the current process, pain points, and successes
- Created desktop and mobile designs, annotated user flows, and prototypes
- Interacted with architecture, backend, and frontend teams to ensure that the design is feasible
- Had design reviews with stakeholders, frontend team, backend teams, etc.
User Research Summary
- Upon speaking with a few techs, we quickly found out that they disliked the current system describing it as “military-ish”.
- “It is too military-ish or like an engineer built it”
- Techs mentioned referencing the OSSLog at the start of the job, in the middle of it, and sometimes even after completing the job – they use it at all points of a job! They expressed that it was a very important tool they use daily and would greatly appreciate if it was more readable.
- “It is probably the most useful tool that I use on tickets daily”
- “The OSSLog is a great tool to see who has touched what when. Separation and/or grids is needed to ease readability.”
(Initial Designs x 3) + Usability Testing
These are the first three iterations of this design on mobile based on feedback from design reviews and usability testing.
- Starting from the left, since this is a long log I figured that a search function would greatly help techs if they were looking for a specific word or error. They might also want to refresh the data manually instead of waiting for the auto update every x minutes. The ticket number and circuit number are right under OSSLog and then the entries in the OSSLog are in reverse order (newest first and oldest last). The longest OSSLog is about 100 pages which I decided to use a paginator for so the tech could navigate through the pages and entries. Each entry as seen above contains a date, timestamp, ID, FCT, event type, and activity description which is a lot of information to digest - I decided to use a collapsible card only showing the ID and timestamp + date. When testing, we found that techs like to scroll and did not like the paginator, it was also hard for them to expand and read all of the cards - they mentioned quickly scanning the OSSLog and the search would come in handy.
- Attempt # 2 - use normal cards and no paginator. Techs also suggested that we remove event type because they never use that so I took that off. Another round of testing and we got more thumbs up than before but something was missing? Techs said the cards were wasting space and they wanted to see more text on the screen.
- Attempt # 3 - no cards, got it :) This called for a completely new component with different margins with text almost to the edge of the screen and line separators.
Final Designs
After a few usability tests… This is what we got! The alternating colors were nice to have to differentiate between entries. Techs only truly look at the activity description. They also wanted a link to the original system (WFA Viewer) in case there’s a parsing error or the entries are not displayed correctly.
“Alternate shading is an effective way to separate entries while saving space.”
“There’s only so much you can fit on a phone screen, and I think this does a great job on putting the emphasis on the activity description”
“The alternating color scheme makes it easier to follow with my eye!”
Product Successes
- Since the OSSLog is reviewed multiple times for a job and scrolling is easier to do with a finger instead of a mouse, techs are more likely to view the OSSLog on their phones - this resulted in a better and more accessible experience and a clearer / better formatted OSSLog.
- No need to access WFA anymore and techs can search the OSSLog - this saves them a ton of time which in the long run results in cost savings because the techs have more working time to do other jobs and close out a job faster.
- Users don’t need to leave Atlas to read job history - one less headache = happier techs.
Next Steps
This feature ended up getting developed, tested, and deployed to production within a few weeks after handoff. We got great feedback on it from users and I was given a similar feature to work on. When implementing that one, a tech pointed out that after scrolling down, if they wanted to go back up, it was hard to do so and we ended up implementing a scroll to top button on the lower right corner and added it to the OSSLog as well (button not pictured here). The OSSLog ended up being a template and reference for future WFA doc integrations.
