From requirements
to a product
people can see.

The problem behind the dashboard

Consultants needed to compare procurement spending, pricing, and savings. But collecting the information meant working across scattered sources and repeatedly going back to colleagues. Before we could make comparisons useful, we needed to understand how information would enter the product, who would prepare it, and who would review it.

Why documents were not enough

Requirements arrived through presentations, PDFs, and conversations with different stakeholders. Those inputs described parts of the problem, but a collection of documents was not yet a product structure.

The product direction was already defined, but the documents did not give the design team a shared picture of the experience. I brought stakeholders into a workshop so we could question requirements together, make responsibilities visible through early wireframes, and identify what still needed an answer.

My intervention

I conducted a three-day client workshop in Bangalore with Kearney colleagues and client participants who travelled from Mumbai. The first two days focused on discovery and project requirements. On day three, frontend and backend development leads joined us to discuss technical feasibility.

The decision: design beyond the dashboard

I framed the design around the responsibilities behind a comparison, rather than the charts alone. Consultants needed to explore benchmarks; other people needed to contribute, prepare, and review the underlying information. Mapping those responsibilities gave the team a structure for designing the connected experience.

The resulting interfaces distinguish four roles: consultants, power users, administrators, and subject-matter experts. The screens below show how those responsibilities translated into comparison tools, data contribution, coordination, and review.

The product challenge

Consultants lacked a central place to discover and compare suppliers. Supplier Prism aimed to help them find relevant suppliers, build shortlists, compare information, and take that information into their work.

My contribution

I combined design management with hands-on facilitation from the beginning. With client-side participants and frontend colleagues, I worked through the proposed experience and the questions it raised. The workshop moved from the problem statement into discovery, role needs, and a shared view of the experience.

The leadership lens

The workshop connected two sides of the product: helping consultants discover and compare suppliers, and helping the people maintaining the information respond when something needed updating. That made information quality part of the experience discussion, alongside search and comparison.

What this added to the design brief

Discovery brought search, shortlisting, comparison, and information updates into one connected discussion. My management role was to help the team work from that shared understanding, while staying close to the hands-on design work.