Case study·Discovery lead·Gilead Sciences·2019–2020

The 30-app problem

Gilead Sciences had built the software they needed over a decade — piece by piece, one micro-app at a time. By the time we arrived, there were more than thirty of them. Nobody was using most of them. This is how the discovery happened.

Outcome

A unified platform replacing 30+ legacy internal micro-apps, signed off on wireframes inside a 5-week discovery window. For the first time, team-level activity became visible to executive leadership without anyone assembling a spreadsheet. The client pulled Phase 2 forward by two months.

Context

Gilead Sciences is a biopharmaceutical R&D company with roughly 15,000 employees worldwide. Like most enterprises that grew through the mobile era, their internal tooling was a layered accumulation: thirty-plus micro-apps built on top of SharePoint, each solving a narrow problem someone had urgently needed to solve — three years ago, or seven, or ten. The apps were slow. Security posture was uneven. The API surface was missing in places it needed to exist. And employees had quietly, individually, gone back to the tools they trusted: email, pen and paper, and the shared drive.

The mandate was to propose a replacement: a single cross-platform internal app, iOS and Android, mobile and tablet, that people would actually open. Five weeks of discovery. Two weeks on-site in California, three weeks in Bucharest with the development and management teams. Sign-off on wireframes at the end, with user stories locked.

My role

I led discovery. In practice that meant three things: build rapport between Gilead’s stakeholders and the engineering team so real decisions could happen in the room; translate business goals into a prioritized feature set anchored to what users actually did; and produce the wireframes and user stories that would unblock engineering for Phase 2. I was not the only designer on the project, but I was the one in the workshops with Senior Directors and VPs, and the one whose name was on the sign-off.

Three decisions that mattered

1. Reframe the ask from “build a better app” to “find the right thing to build first.” The client walked in with a feature list. It included search (which their existing tooling did badly), an employee directory, a company-news feed, and several workflow-specific tools. My first intervention was to slow that down. Before the timeline allowed any wireframing, I ran a Lightning Decision Jam with Senior Directors and VPs — deliberately structured so the most senior voices in the room were not the only ones heard. Three days of user interviews followed, six participants across HR, Legal, Medical Affairs, Physical Security, Business Strategy, and Library Services. What emerged was that the feature at the top of the list was not the feature driving the most daily friction. Priorities shifted. One headline feature was de-scoped for Phase 1; another moved up. The workshop wasn’t theatre — it changed what got built.

Search — can’t find anything. It’s not a Google. ‘Did you mean…’— user interview, Gilead Sciences, 2019

2. Design for the org that needed to see itself, not just for the person holding the phone. The research surfaced a second, quieter finding: the real cost of the fragmented tooling was not user time. It was leadership blindness. Senior Directors and VPs had no way to see what teams were actually doing day-to-day without requesting a spreadsheet from someone down the chain. The app’s information architecture ended up doing two jobs: surface the actions a field user needed in the moment, and produce — as a byproduct of those actions — the signal that leadership had been missing. That reframing is what turned the project from an app refresh into an organizational tool.

3. Trade depth for discoverability in the first release. Thirty-plus micro-apps is a lot to replace. The compression move was to design Phase 1 around a small number of high-use workflows done well — search, directory, news, and a tight cluster of team-specific actions — and explicitly plan for the rest to be absorbed in later phases. The architecture was built to extend. The first release was built to be used.

Before30+ micro-apps on SharePoint“Nobody is using most of them.”Slow. Missing API. Fragmented permissions.Discovery5 weeksAfterOne cross-platform internal appSearch & DirectoryThe highest-use surface. Done well first.Team workflowsA small cluster. Extendable architecture.News & AnnouncementsAbove-the-fold by design.Leadership could see what teams were doing,without anyone assembling a spreadsheet.
Fig. 1Information architecture, before and after. Editorial illustration; not the delivered UI.
When you post announcements on Gnet about events and notice, you have visibility for only 4 of them. If yours goes below the fold, nobody will ever see it.— user interview, Gilead Sciences, 2019

That quote landed the news-feed decision. The previous solution surfaced four announcements; a fifth was invisible. The replacement had to handle the long tail of internal communications without relying on someone posting at the right moment of the day.

Five weeks, two locations

The compression was unusual for a discovery phase at this scale. Two weeks in California, three weeks back in Bucharest working tightly with engineering and management. The two-location split was not accidental — being on-site meant the stakeholder workshops and user interviews could happen at the pace stakeholders could offer, not at the pace of scheduled video calls. The Bucharest weeks were where the wireframes got pressure-tested against engineering reality.

Week 1Week 2Week 3Week 4Week 5on-site, Californiaremote, BucharestWorkshops & interviewsLDJ, stakeholder + userFeature reprioritizationScope changes, signed offUser flows & IAFlow diagrams tied to the new priority setWireframesPressure-tested against Xamarin, SharePoint, API, securitySign-off
Fig. 2Discovery timeline. Red indicates on-site weeks in California.

What shipped and what it changed

At the end of the five weeks, wireframes and user stories were signed off and engineering had a clear Phase-1 scope. The client’s reaction was the useful signal: Phase 2 was pulled forward by two months, and a separate team at Gilead was briefed to run a similar discovery on an adjacent project with — explicitly — UX discovery as a mandatory first phase.

The piece I’ve thought about most in the years since is the leadership-visibility outcome. It was not in the brief. It emerged from research. And it ended up being the thing that made the new platform indispensable — because once leadership could see the organization in real time, the cost of any team staying on the old tools became visible too. That’s the shape of internal-tooling work I find most interesting: where customer experience, operator efficiency, and organizational legibility share one surface.

What I take from it

Stakeholder priorities are never locked until research shows them something they didn’t know. The LDJ was the moment two senior executives reprioritized a feature set they had arrived defending. Nothing about the meeting was confrontational; the exercise made the reprioritization feel like a discovery rather than a concession. That is the move I carry into every enterprise discovery since.

The second thing is narrower: internal tools make the org visible to itself. A well-designed operator surface is also an intelligence surface. That idea is what I brought to every complex B2B project after Gilead, and it is the lens I use when I look at internal platforms today.