Designing an Enterprise

Designing an Enterprise

IT Portfolio Management MVP

IT Portfolio Management MVP

NDA

Enterprise

Modernization

Time:

Time:

6 months, 2018-2019

6 months, 2018-2019

6 months, 2018-2019

Role:

Role:

Sole Product Design Consultant

Sole Product Design Consultant

Sole Product Design Consultant

Scople:

Scople:

Research, Design, Cross-functional collaboration

Research, Design, Cross-functional collaboration

Research, Design, Cross-functional collaboration

Type:

Type:

Internal Tool

Internal Tool

Internal Tool

Outcome

Outcome

At the go/no-go decision, every business segment voted to continue investing in the tool except one, which opted to evaluate a commercial off-the-shelf platform instead. The remaining segments funded an enhancement phase.

At the go/no-go decision, every business segment voted to continue investing in the tool except one, which opted to evaluate a commercial off-the-shelf platform instead. The remaining segments funded an enhancement phase.

Introduction

I consulted as the sole designer on a six-month MVP for the organization's technology group: a new experience for a multi-user project management tool. The tool's data fed the organization's resource planning platform and rolled up into annual reporting to the CFO, so the accuracy of what users entered carried consequences well beyond the tool itself.

The Problem I Was Handed

The engagement was framed around a single premise: employees were careless when entering data, and the project management tool had accumulated corrupt and missing records as a result. That corruption produced the inaccurate reporting leadership wanted fixed. I treated the premise as a starting point rather than a conclusion, and went to the field to understand why accurate data entry was hard.

The Work

I partnered with the Product Owner to interview 10 users, including two teams of three. To understand the workflow itself, the Design Principal and I ran three working sessions where business leads walked the product team and us through the end-to-end process.

User Insight

The research pointed to a structural cause. The same information lived across multiple tools, and when a value changed in one place, say a project's name or assigned stakeholder, nothing propagated the update or flagged the others as stale. No single tool held the authoritative version, so users couldn't tell which copy was current. Careful people were producing unreliable data because the system gave them no source of truth to work from. Teams had responded by maintaining shared spreadsheets as the "true" record: a fragile workaround that created version-control, auditing, and ownership problems of its own.

The working sessions surfaced a second, compounding problem. Each segment used different terms for the same workflow. Without a shared vocabulary, teams couldn't agree on where a project stood or who owned it at a given stage.

Underneath both problems was the same root cause: no single trustworthy record, and no shared language to describe the work.

Designing for a single, trustworthy source of truth

These insights defined three requirements:

01 · Transparency through audit history
Captured who changed what and when, with versioning, turning later investigations from guesswork into a clear trail.

02 · Accuracy through real-time validation
Caught mistakes at checkpoints through error alerts, validation checks, and owner reviews, preventing the bad data that had corrupted reporting downstream.

03 · Usability through an intuitive architecture
Gave users visibility into project status, events, data, and ownership, so they could see how work moved through the process and where their responsibilities fit. In-context definitions let users confirm what a term meant, right where it appeared.

Design & Validation

Early in the project, I concept-tested a project detail page built on my initial assumptions, then iterated from user feedback. That one-on-one cycle stretched delivery time, so at the PO's request and in line with the organization's process, we moved to group validation sessions with stakeholders. I iterated each design from the feedback those sessions produced.

The method had a real tradeoff. Feedback was immediate, but with over twenty people in a session, quieter participants went unheard and the most forceful voice carried the room. User acceptance testing offset this: at the end of each sprint, business units received a set of instructions and tested on their own time, then reported back. The asynchronous format recovered the feedback the live sessions suppressed and gave us a clear list of what to fix before the next release.

Working with engineers

There was no existing design system, so in the first sprint I specified common components loosely based on patterns already familiar from other tools in the organization. In later sprints, the PO, Business Analyst, and I met with stakeholders to groom user stories, interaction flows, and UI mockups. For any new interaction, I ran parallel sessions with engineers to confirm feasibility, then attached annotated wireframes and related mapping to Jira for implementation.

Whiteboard map of the end-to-end process, built from business leads' walkthroughs in the working sessions.

The project detail screen, with callouts marking the audit trail, validation checks, and in-context definitions.

Annotated wireframe specifying component behavior and interaction states for engineering handoff.)