From manual approvals to guided governance
Guided digital tool that tells a project exactly what it needs, based on its type and size.
The Gist
The Problem
To open a new store the project teams needs to move through a formal approval process. A series of checkpoints, varying depending on the project type. Each checkpoint means preparing documentation, submitting it for review and recieve approval.
I worked closely with the product specialist and product owner from day one to understand the problem, alongside the business stakeholder throughout. The hard part was it's complexity. The process involved many stakeholder groups and many rules, including, as research would show, a number of exceptions that existed only as informal practice rather than written policy.
- Hundreds of individual reviews happening across the organization each year
- A significant amount of time spent preparing documentation for those reviews
- Several weeks needed just to consolidate the material for a submission
The Journey
Talking to the users
I started by interviewing the three user groups: the teams preparing material, the specialists reviewing it and the people approving it. Each experiences the process differently, so understanding all three was the starting point.
Mapping the Full Journey & Understanding the pain points
The product specialist and I mapped the full project journey, based on interviews and on reading how the organization runs. Then we ran five workshops in Miro, over Teams, with participants working in different countries and different roles. They put their own pain points directly onto the map.
I took what came out of those workshops into affinity mapping. One workshop on its own produced more than 40 grouped observations.
With the journey and the pain points documentet it helped to guide the scope and roadmap for the product team.
- Delays and lost context in back-and-forth review comments
- Uncertainty over which document version was current
- A slow, manual sign-off process
- Repeated manual copying of the same information across documents
- Inconsistent quality depending on who prepared the material
Designing
The main structure of the product was around guiding the user through the process. I designed the tool to read a project's type and present only the relevant approval steps and required documentation for that specific project. I also worked closely with the team behind another internal tool to pull in as much existing project information automatically as possible, cutting down on manual data entry.
From the user research two findings stood out: not knowing which document version was current and losing track of review comments.
For the first, every checkpoint got its own space where the related documents live together with version control, so anyone can follow how a document changed over time.
For the second, a live comment log. Teams and reviewers comment in a thread tied to the document or the step it's about. You can see at a glance what's still open and what's been dealt with, without reading back through a mail chain.
Setting Up a Feedback Loop
Given how spread out this user group was across the organization and the world, I set up a recurring group of stakeholders to give fast feedback and flag changes early.
Designing Alongside an Evolving Process
While I was designing, the organization was working in parallel on improving and changing parts of the underlying process itself. That meant incorporating changes as they came, rather than designing against a fixed target.
The design also started from a strict, rules-first approach. Once the tool was in production, a number of exceptions became visible that had never been formally documented. They'd simply been handled case by case. That shifted the design toward a better balance between structure and flexibility, rather than strict rules by default.
Usability Testing Before Launch
I ran two rounds of usability testing before launch, with a group of participants across roles. This validated the design and confirmed people could find what they needed and follow the process end to end.
Outcome
Two rounds of usability testings before the launch confirmed that the tool was well structured and key functionality was well received. The tool launched successfully into a genuinely complex process.
A year into use, I ran follow-up feedback sessions with users across roles. People described the tool as simple and organized compared to the previous, more manual approach.
The tool also collects rating feedback continuously from users across the organization. Over 165 users have rated their experience so far, spanning dozens of departments and countries, with an average rating of 4.4 out of 5.
Takeaways
Designing inside a defined process
The clearest lesson from this project was about designing inside a process with many rules and exceptions. There's a tension between giving people enough structure to be guided and enough flexibility to handle cases that don't fit the documented rule. You can't see that tension while the process lives in documents, because everyone works around it quietly and nobody has to write the exception down. It only shows up when you put the process online and something has to decide what happens next.
“One of Amanda's greatest strengths is her ability to bring simplicity to complex challenges. She consistently transformed complicated requirements into practical, user-friendly solutions while remaining open to feedback and continuously improving the outcome. [...] The solution has successfully achieved its original purpose, simplifying a complex landscape and creating a more efficient and reliable way of working. Invex effectively balances flexibility and simplicity, allowing it to adapt to changing business priorities while remaining easy for teams to adopt and use.”
— Nese Aykol, OCN Design & Project Portfolio LeaderRead the full testimonial →