Service Design · 2025
Government Innovation Incubator Portal
End-to-end incubation management - from application to graduation
Government incubators have a design problem nobody names correctly. The assumption is that the hard part is nurturing startups - the mentorship, the funding decisions, the graduation criteria. But the real friction is operational: reporting that takes a team three weeks to compile, service requests that bounce between four inboxes before anyone acts, approvals that stall because nobody has a single view of where any entity is in its journey. Innovation ecosystems don't fail because of bad strategy - they fail because administration drowns everyone before strategy has a chance.
A partner agency brought our studio in to design the incubation management portal for a ministry-backed program. The brief was clear enough - digitize the operations. What we found in the work was a more specific problem: every stakeholder in the ecosystem was navigating a different version of reality, and the system needed to create a shared one.
What I owned
I led experience design across the full product: user-story definition across seven personas, functional specification for five core modules, and prototyping for six key surfaces - the landing page, the entity dashboard, the service status tracker, the service catalogue, the workflow builder, and the command-and-control dashboard. This was greenfield, so the decisions weren't about improving an interface - they were about defining what the product fundamentally was.
Treat the service catalogue as a marketplace, not a menu.
The original framing of “available services” was a list - here's what the incubator provides, contact your relationship manager to discuss. That contact-to-discuss step was costing 100 hours per entity per service-scope discussion and generating a 20% resubmission rate because scope was never agreed upfront. The fix wasn't faster responses - it was a different model.
I redesigned the catalogue as a true marketplace: each service with a clear scope, defined deliverables, a published SLA, and a rating from entities who'd used it. It surfaced recommendations based on where each entity sat in its journey - a Build-stage entity never waded through Graduate-stage services. An entity could browse, compare, save to a wishlist, and submit a request with a pre-populated brief in one flow - no ambiguity, no scope drift. The relationship manager saw exactly what the entity saw, so the conversation started from a shared document rather than from zero. That shift, from service list to marketplace, is what collapsed a 25-interaction request pattern into something manageable.
Make the workflow builder the operator's tool, not the developer's.
Incubation programs change - new stage-gate requirements, restructured approval chains, shifting compliance criteria. If every process change needs a developer, the system is obsolete before it ships.
I designed the governance module around a drag-and-drop workflow builder: operators connect stages, assign reviewers, set conditions, and publish updated processes without writing code. The engine underneath was a standard BPMN process engine, but operators never saw the syntax - they saw a canvas that matched how they described their processes out loud. The trick was opinionated templates: most programs don't need to design a process from scratch, they need to adapt a familiar one - so operators started from a stage-gate flow that matched their archetype and customized from there.
Make the 24-day report a dashboard the director checks before their morning meeting.
The most striking number from discovery: it took the team 24 working days to compile a single quarterly report - a full month of operational time, every quarter, aggregating data that already existed in the system, just not together. Leadership couldn't decide in real time because real time didn't exist for them.
The Command & Control Center ended that. A live operations dashboard - entity progress across the five-stage journey (Setup → Build → Grow → Graduate → Spin-Off), service-request status, approval-queue visibility, program KPIs - refreshing from the portal's own data. The report became a scheduled export from a screen the director already had open.
What mattered most wasn't the layout - it was the data model underneath. I worked with the technical team so every entity action emitted a logged, queryable event. Get the data model right and the reporting problem is structurally solved, not cosmetically hidden.
How I worked
Discovery ran across all seven personas - the ministry (policy compliance, portfolio visibility), the operator (day-to-day management and reporting), the relationship manager (entity support and service coordination), the incubated entity (service access, milestone progression), the potential incubatee (the application journey), partners and investors (opportunity visibility), and the citizen (program awareness). Seven personas means seven different mental models of what the system is for, all served from one shared data layer. I wrote user stories across the five modules covering 36 distinct processes, prototyped six core surfaces, and wrote the functional specification that mapped each story to a module, defined the logic for each state, and gave the build team its acceptance criteria.
What I'd do differently
I'd push for community-module co-design with entities earlier. The community and events module was the one area we designed for a need we understood in theory but hadn't pressure-tested with the people who'd use it. Incubation community dynamics don't transfer cleanly between programs - two or three entities in a room would have sharpened those flows considerably.
Full process documentation available on request.
Client names are kept confidential - projects are described by deliverable and region. Happy to walk through the full story on a call.
Request the full case study