If, like me, you’ve ever been involved in the redesign of a ‘simple digital service’, you will know that there is perhaps no such thing. Very few services, if considered carefully are either simple, or in fact entirely digital.

Even when constrained to ‘just’ the digital bits. Design work involves many small decisions that are often completely missed by the person navigating through your user flow. Perhaps because you made it easy for them, or perhaps because they never even able to make it there in the first place.

Way back when, teams might map out the steps taken by users as wireframes, line drawings of screen flows with a few key design elements on each. I can remember doing this on graph paper notebooks or even ‘sketchified’ in Axure.

You’d probably then move to some form of ‘low fidelity’ prototype. Adding hotpots to your digital wireframes or lovingly crafting paper prototypes, layering up buttons on your pages.

Paper prototyping and other low fidelity methods normally associated with the early stages of a design were already being roundly dismissed as a waste of time in the days of prototyping in code, Figma design systems and such. I’ve never agreed, for reasons I’ve written about before.

With the age of Ai powered interface creation tools well and truly upon us, its worth dwelling again on this.

This isn’t a post about Ai tools, what they can do, how quickly they are developing, or whether designers will be out of a job. Other people are better qualified to write about tools, or more opinionated on the impact Ai will have than I am. But I do think its worth considering the new opportunities, the new risks, and ultimately the fact that the same things will still be hard regardless.

I’m interested in how we adapt our approaches to prototyping and what that means for making design decisions about products and services that ultimately get used by real people, not posted on social media for likes. This isn’t a post about artificial intelligence, its a post about design methods, sorry if I tricked you into getting this far.

When leaders get design tools

I’ve been advocating for leaders of all kinds to embrace prototyping as a way of working. In the past I’ve run workshops with public and private sector leaders introducing them to ideas like paper prototyping, or prototyping in PowerPoint. The aim has been to encourage people to use the tools they have to communicate the ideas they have.

The perceived risk of ‘non-designers’ prototyping didn’t concern me. The tools these people had access to weren’t ‘design’ tools, it was almost impossible to make a shiny thing that look finished, but had no thought behind it. It was much easier to show your thought process, but not in an especially polished way.

What I was really doing was giving them a mechanism to communicate ideas, in a level of interactivity they had previously thought out of their reach. Enabling better communication is a much undervalued output of prototyping. The more people who can speak the language of prototypes, the better the outcomes of the design work from my experience.

Of course now Ai is on virtually every senior leader’s radar, in a way that Axure, Powerpoint or Figma never has been. Ai is being positioned as this catch all super-human power that people can tap into to broaden their skillsets, and shortcut others with the click of a button. I’ve heard stories of CEOs being asked to prompt Ai design tools with the design of their new company website and then being gobsmacked with how quickly a plausible design is presented back to them.

At first glance, you could argue everyone’s ability to communicate their ideas has massively increased. Life-like (and sometimes functional) interfaces at the click of a button, based on a text description. Power to the people. Democratising design and so on.

Prototyping at speed

In some ways this has always been the party trick of design sprints, or a sharp Interaction designer with a prototyping kit. Turning around plausible interactive prototypes in a matter of hours rather than weeks. Arguably all we’re doing is shortening the timeline even further.

Adopting new tools always has the potential of increasing the output of a design sprint. Whether you’re strictly adhering to the 4 D’s or just trying to learn fast and make things, bringing multiple ideas to life in parallel so that they can be tangibly experienced in some way is an incredibly powerful ability to have.

But as anyone who’s ever completed a design sprint knows, making a visually appealing, mostly functional digital thing is probably less than 5% of the work. An Ai generated interface – even if done in 3 minutes, instead of 3 hours – can only save so much time because that is such a small percentage of the work to ship a thing.

Design work is the sum of decisions made based on evidence, that can be justified, critiqued and implemented with confidence. When the senior leadership want to understand why certain interaction design decisions were made, shrugging your shoulders and saying it was Ai’s idea….probably won’t go down too well.

Getting to that point is another matter, exploring possible adjacent futures, ideation, divergent thinking, whatever you want to call it. Surely this is where ‘generative’ Ai comes in. Generating ideas at speed. But the ‘design’ tools all seem a bit narrow minded to me.

Entrenching assumptions

Taking a design approach is supposed to be intentional about challenging assumptions and explicitly exploring alternative ways to solve problems. As designers we are often already guilty of falling back on designing screens, when none are necessary. When those screens are even easier to conjure out of a carefully chosen 20 word prompt, we will have to work harder to remind people to stop and think about what other options there are.

We need design solutions to be explored and prototyped in a way that considers the problem to be solved, not just the solution to be designed. Equipping people with the ability to generate workable interfaces in a matter of seconds presents a risk of that being the default route – even more than it already is.

I’m not the first to point out that when all you’ve got is a hammer, everything starts to look nail-shaped. As anyone who has seen a multidisciplinary software team realise they need to be a cross-functional service team will know – starting with the assumed output in mind is risky business. Within engineering circles people discuss the idea that the ‘best code is no code at all’ because of all the effort and money it takes to maintain it. If you can solve your service design challenges without building or maintaining software, you should.

We’re talking about Ai design tools, but they’re really ‘tools that make things that look and work like websites’. So much of what I/we are designing doesn’t match that description. Service design should consciously be designing interactions with humans, removing gaps between organisational silos to prevent people getting lost etc.

We already know its flawed to assume some screens can solve a service design problem, so why would we think a design tool that can only design screens will do any better?

Any set of tools that make it even easier to generate interfaces, without any critical thinking about whether that’s the right solution, risks entrenching some of the worst parts of ‘digital by default’ – namely thinking all the real design decisions live within the screens. The real decisions making needs to happen beyond and behind the screens.

Prototyping beyond the interface

There are relatively well documented service prototyping methods, but because they reflect *services* i.e. not just digital interfaces, you can’t generate them using an interface generator. Ai can’t gather your stakeholders in the room alongside your users and facilitate a session that explores sensitive topics brought to life through experiences using a few scraps of cardboard you found in the skip outside.

I’ve yet to see someone excitedly pronounce that they’ve discovered a tool to prototype services in seconds. Inevitably there’s interesting ways to use the tools, but I worry about describing them as ‘Design tools’ without pausing to reflect.

So what next?

The questions I keep coming back to is ‘how can we use new tools to prototype more effectively?’ Not necessarily more efficiently. So for me I’m left wondering:

• How can we use new tools to generate ‘divergent’ concepts to design challenges at speed, without them resorting to only generating interfaces?
• How might new tools emerge that enable us to prototype services, and how might we use some of the ‘critical friend’ capability they already have to start with.
• How do we communicate and demonstrate to leaders the complexity that lies beneath the screens, so that they recognise the limitations of Ai ‘Design tools’?

Like I said, this was not a post about Ai, but about prototyping. Collectively we as people designing services should pause and reflect on whether we’re making the most of the ways we already have to generate a wide range of concepts to tackling complex service challenges, without resorting to screens by default. The more robustly we take that approach, the better we can recognise the value and the constraints of the emergent design tools we’ll be getting in our toolbox.