Internal Project Tracking Application for T-Mobile

T-Mobile hired me to design their new Dev Project Tracker application.

The Problem

T-Mobile’s myriad software development projects are a complex web of connections between releases, projects, applications, teams, owners, deliverables, schedules, code, etc, and those projects were all being managed and documented through Sharepoint with no representation of those important data connections. This lack of association between related items led to significant inefficiencies, missed items, twice-done work and more.

My Role

I was hired specifically for this project and served as the sole UX Designer. I worked in close partnership with the Product Manager, Lead Back End and Lead Front End Developers, and functional stakeholders to discover business and user goals, define requirements, define workflow, create information architecture, define interaction model, design, wireframe and specify every page and page state across all user types/permissions levels, validate and iterate design work in flight, and create and document visual styles.

 

I conducted working sessions with each representative group  to better understand what information they needed to know and what information they needed to communicate. I worked with the product manager to define, categorize and prioritize requirements, to understand data duplications, and to simplify language usage. I mapped workflows. I sketched screens to establish a high-level interaction paradigm, to validate and correct understanding of each group’s requirements, and to get buy-in from stakeholders. I worked in tight partnership with a product delivery team, typically spending 2-3 hours of our days together whiteboarding and working through problems. I created a full design specification (behavioral and visual) for every feature area, often working simultaneously and hand-in-hand with the engineers building the application to design and agree on solutions as they were built. I built a fully annotated UX Specification and produced high-fidelity mockups and a foundational style guide and pattern library. I worked in partnership with a researcher to define questions to be asked.

The Solution

The Product Manager and I teamed closely to accomplish the following:

We inventoried all information being tracked in the Sharepoint system to establish duplicate data points, possible missing information and possible extraneous information. This inventory gave us insight into the manner in which functional groups operated, their likely needs, where there was redundancy and/or contention between groups, and what questions we needed to ask.

We conducted in-depth interviews of every functional group involved in the software development process to understand how they operated, their needs, their timing, their terminology and more. Some of these interviews revealed need to conduct working sessions with multiple groups in order to work through the particulars of their touch points.

After this collection of requirements, I created a set of 20+ sketches to represent our understanding of those requirements and the high-level workflow that would accommodate them. A few of those sketches are presented here:

Previous
Next

These sketches were validated with the groups with whom we had spoken. Sketches were presented as applicable to each group and course corrections were made based on their feedback.

At this point, product owners and I prioritized functionality and order of needs and began design work. We attacked design work in a very collaborative manner, holding regular working sessions twice weekly. Design of information architecture and significant functionality were discussed in depth in frequent and ongoing whiteboarding sessions with PM, and front- and back-end engineering leads. Functional representatives were invited to sessions relevant to their particular functions. Solutions were negotiated in person as far as possible to accommodate an extremely agile process—a few whiteboard sketches are shown immediately below:

Previous
Next

I used whiteboard sketches and negotiated agreements to refine and document information architecture, application flow and interaction design.  Images from some of these documents are shown immediately below:

Previous
Next

As functional and behavioral design was completed in draft and iteration and signed-off on, I created mockups and redlines to inform final front-end development. A few of those images are presented immediately below:

Previous
Next

The Results

Functional areas were released incrementally as completed and the first round of the full application was in production within 9 months. Quantitative validation was not done while I was still on the project, but an independently-conducted qualitative survey returned excellent participation and positive feedback on the new tool, its ease of use and its completeness.

Other Projects