Thoughts on AI in a product design process

Where I work at the moment (ELMO) they are very forward thinking and thoughtful about the use of AI in the product design and development process. I’ve been lucky enough to observe and be involved in a lot of this exploration.

My thoughts are constantly evolving on this subject but, this is where my head is at at the moment in regards to where in a product design process AI has potential to allow us to move faster and be more effective, and where it risks creating a feeling of progress, but might degrade our product decisions in ways we might not discover until those decisions have already made it to market.

These aren’t theoretical areas, we are actively working on each of them in our live process at ELMO and I’ll add a follow up post when I have time about a method product teams can use to integrate AI acceleration into an already established design process.

• Innovate new ways of working. Enabling activities that simply weren’t practical before. For example handing over a functional prototype instead of static designs, with automated design system compliance checks and walkthrough flows built in. A designer at ELMO has built a tool that makes this feasible enough that it might replace some of previous Figma based hand over documentation.
• Accelerate how we work, improving the speed or quality of what we already do. For example on quality, rapid prototyping lets us explore complex interactions far more realistically than sketching out static flows. On speed, we can create a more direct path from specification to working feature, generating both the design and the production code (see note 1).
• Shortcutting process, automate laborious low-skill/low nuance steps. For example, automated assessments of design system compliance are implemented.
• Unblock design pinch points, keeping design moving when the pipeline is full. Design capacity is finite. When the team is unavailable, product managers and engineers could use AI to generate known quantity pattern based designs, so work doesn’t stall waiting for us (but see note 1 again!).

Like any use of AI there are risks that we need to be cognisant of. I think these risks broadly align to general risk when using AI, in particular around degrading expertise and understanding through removing the hard work that generates a deep engagement with a topic, and a drift from good decision making caused by reasonable feeling generated reasoning that drifts from real life context. In product design these manifest as:

• Shallow understanding. If we shortcut understanding our customer needs and go straight to generation, the product team’s understanding of the problem gets thinner. The hard work required to turn ambiguity into insight, and trying different approaches to understand why some solutions work better than others builds a deep understanding, and removing that hard work risks degrading that understanding.
• Surface-level critique. Reviewing a generated design is different from creating one. Feedback drifts towards surface UI details as it is more disruptive to undo work that is flawed at its foundations.
• Bypassed quality checks. The same shortcuts that save time can quietly sidestep the checks and balances in our design process.
• Drift from reality. In research and testing, AI can produce realistic, user-like results. If we lean on them too much, we drift away from what our actual customers think and do.
• A transition dip. Adopting new ways of working (not just AI) will likely cost us some pace while we learn.

I think if we keep this framework (for lack of a better word) in mind as we integrate new ways of working we are extremely likely to be able to improve the speed and quality of product design. As I said I’ll write up how I think this should work soon.

I think it’s useful to think of automation design process as a spectrum. At one end, we should be aiming to go directly from specification to working product, with little or no manual design intervention. At the other, we need people with a strong understanding of the context, users and human behaviour to lead the design process, using AI as an assistant where helpful.

For example, I recently had a relatively straightforward requirement to provide an audit log of activity in a system. There’s really only one way to do this, a page containing a table using an existing pattern in our design system, there should be no reason why we couldn’t generate the actual page directly from the specification. In the future that should bypass me except for a QA check, going straight into design review and UAT.

At the other end of the spectrum are problems where there are many possible ways to approach a solution, where the context is complex and where understanding user needs and behaviour is critical. These situations require human judgement, solution exploration and a deeper understanding of the problem. AI can still help with research, exploration, prototyping and execution, but a person should be making the key decisions and carefully crafting the experience. Regular discovery and testing with real users remains essential.

We should be aiming to operate across this spectrum, choosing the level of AI involvement that will get us the best product outcome, and through that the best business outcome.