A technician arriving at a customer's site and checking what she needs using Atlas on her tablet.
Atlas, our mobile and desktop app for AT&T field technicians, was developed to replace disparate legacy systems. One of my many initiatives was enhancing equipment documentation for technicians.
Through collaboration with my team, I designed and delivered a seamless user experience which saved technicians time, increased equipment documentation rates by 37%, and saved multi-million dollars.
However, technicians haven’t been reporting their transactions. Costs are piling up because plugs are going unaccounted for and unnecessarily reordered.
As a UX designer for the Atlas platform (which was the new, streamlined mobile + web app to be used by all AT&T field technicians), I was asked to integrate the legacy plug management functionality in a two-week sprint.
The request specified not to let technicians mark a customer job completed until they’ve reported their plug transactions. I was concerned that this approach would increase resentment in our users.
My job was to convince my team that we never blame the user. If technicians aren’t doing as the business desires, it is because they haven’t been enabled to through a tool that truly meets their needs.
I leveraged user interviews and contextual inquiries to understand technicians' current processes and priorities around plug management.
.jpeg)
Synthesizing the research, I found two overarching pain points.
1
Repeated manual entries
Technicians repeatedly have to enter lengthy identifying codes, which is time-consuming and frustrating, especially when they are juggling many things at once.
2
Confusion on instructions
The legacy interface makes a plethora of fields available to technicians, giving no indication of what to use when. Technicians are expected to memorize instructions, but expressed feeling overwhelmed given the complex scenarios they experience.
By inviting business stakeholders and developers to listen in on user interviews, respectfully vouching for technicians, and storytelling concisely, I built alignment around the following reframed opportunity:
Many of the people who built the legacy plug management process had retired, leaving us with a choppy understanding of it. I used user research and stakeholder discussions to piece together the complex scenarios that technicians encounter and synthesized these into digestible user flows.
Without the budget to build a new back-end system, these are the same high-level workflows that my solution would have to maintain. These evolving artifacts built visibility on the true scope of the design challenge and helped me structure my ideation.
1
Automate and pre-populate wherever possible
If we can automatically capture details such plug ID and plug location, we can remove the burden of manual input from the technicians.
2
Integrate only relevant actions for the context/job stage
During a job, technicians don’t benefit from seeing all the possible actions they could take. They only need the contextually relevant actions to be made available at each step.
Option 1 - standalone section of the app: a section that lets technicians manage inventory outside of any one job, indicating actions like using a plug off their truck.
Option 2 - integrated on each job: the plugs that are needed for the job are pre-populated and can be indicated as ‘in service’ when the technician has installed it.
In user testing, all technicians tested (5/5) preferred option 2. They expressed that when they reach a customer’s location, they are looking at the job tab. Further, since ‘Equipment’ lives in the existing structure of that tab, it’s where they expect to find plugs. I moved forward with this solution.
Due to the tight timeline and having an existing robust design system, I used mid to high-fidelity wireframes to socialize the designs and gather feedback from developers and business stakeholders.
During an installation job, the plugs that technicians need to install are automatically populated under ‘Equipment,’ which sits center screen to convey that it is the most important digital interaction that technicians need to have at this stage. During a repair job, the technician simply indicates which plug out of the ones previously installed at that customer site are defective.
A few development constraints came to light. An infeasibility of fetching previously installed plugs at a customer site meant extra steps needed to be added. I realized the repair process would be best digitally initiated with the technician indicating what spare plug they’ve added to replace a defective one.
However, staying true to the principle of automation, I designed a scanning experience instead of putting the burden on technicians to manually enter codes. Further, developers and designers agreed that building an API to smoothen this process further would be be a priority.
While thorough prototypes and specs were handed off to development, these screens capture the core offering of the plug installation flow and repair flows.
In the primary use case, technicians simply hit “Add” to indicate that they’ve installed each plug. All the nuances that could occur — such as receiving a faulty plug — are handled through peripheral controls showing the relevant follow-up actions. Once a plug has been marked in service, this status is made clear to technicians and they can access details of the plug.
.png)
.png)
.png)
Similarly, these screens capture the essence of the solution for returning a defective plug and adding a spare one. The primary use case is completed by the technician scanning or selecting which spare plug they’re using, followed by selecting which defective plug they’re returning. I designed the search bar to be pre-populated with the type of plug they’re using to balance user efficiency and freedom.
The data we gathered from early adopters was positive — we witnessed a 37% increase in reported plug transactions and a decrease in missing plugs. On the scale at which AT&T operates, this decrease in missing plugs created multi-million dollar savings. The technicians expressed that they are saving a lot of time. That being said, our ears are always open for ways to improve.
The thing I appreciated most about this project was building strong relationships with my cross-functional colleagues and increasing their buy-in to the UX process. As this was one of my earlier UX projects, I became much more confident in handling projects that are complex, change scope, and involve nuanced constraints. To this day, if I feel intimidated by the jargon or intricacy of a new project, I remind myself of plug inventory management in Atlas.