Designing the right environment for the team to be creative became just as important as being creative myself. I introduced design sprints into the discovery process of feature development — and it changed who got to make decisions.
During my time at AVEVA, I focused mainly on enterprise web applications. The reality was a development-led setup: we churned out features and rarely circled back for a second version.
Contract Risk Management software
The product I spent most of my time on was ProCon (now Contract Risk Management), the sole product of 8over8 before its acquisition by AVEVA. It audited communication between the company commissioning a build and the contractor hired to build it, for mega-capital projects where costs ran into the tens of millions and overruns of 40%+ were common.
Over my time on ProCon, I brought it from a database-on-a-screen interface to something with a more considered approach to usability, working with each product owner to visualise features and get approval from product and development before any code was written. Several issues came from this: I became a hero-designer, which isn't healthy, and the product team lacked buy-in for the features we were shipping. That gap showed up later as bugs, because the team didn't understand why a feature existed or how it fit the larger product.
To address the lack of buy-in and move through ideation faster, I introduced a design-sprint ceremony into the agile discovery process. Inspired by the Google Design Sprint methodology, different tasks were applied depending on the problem to be solved.
Our first step was mapping the current experience flow for the problem we were trying to solve. I'd convinced the office manager to paint one of the conference room walls with whiteboard paint — and I'm glad they agreed, because the user flows we dealt with were often complex enough to need the space.
Bring the team along on the journey, just don't name it
The team was given three to five days during the kickoff workshop to address the problem: mapping out the user flow and highlighting pain points surfaced by the core problem, additional user feedback, or our own observations.
