Atlas Inventory Management

I designed a better inventory management experience for AT&T technicians, leading to a 37% increase in transaction reporting and multi-million dollar cost savings.
Enabling field technicians to report their equipment transactions seamlessly when installing or repairing a customer’s internet.
UX Designer, UX Researcher (as needed)
1 UX Researcher, 1 Scrum Master, 4 Developers


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.

A technician arriving at a customer's site and checking what she needs using Atlas on her tablet.

Understanding the Problem


AT&T installs plugs, a particularly expensive equipment item, at customer sites. To keep track of these valuable assets, the business leans on technicians to report the details of each plug they use.

Technicians must access an inventory management website on their laptops and enter lengthy identifying codes to report plug transactions for a variety of complex scenarios.
The legacy plug inventory management website.

However, technicians haven’t been reporting their transactions. Costs are piling up because plugs are going unaccounted for and unnecessarily reordered.

The Business Request

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.

Getting the Technician's Point of View

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.

A technician setting up equipment at a customer site, using his laptop for mandatory reporting.

Synthesizing the research, I found two overarching pain points.


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.


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.

Shifting the Internal View of the Problem

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:

Our technicians need a quick and intuitive way to digitally indicate their equipment transactions in order to feel aligned with their supervisors and spend more time present with customers.

Mapping Out the Current Process

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.

Installation Jobs
Repair Jobs

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.


Design Principles


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.


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.

Testing Two Potential Directions

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.


Initial Wireframes

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.

Key Collaboration with Development

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.

POV: A technician scanning the identifying information of a plug.


While thorough prototypes and specs were handed off to development, these screens capture the core offering of the plug installation flow and repair flows.

Installation Jobs

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.

Repair Jobs

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.


Shipping and Gathering Metrics

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.

Personal Reflection

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.

Go to next project -->