Andrew Duckworth

Creating prototypes constrained by the medium not our skills or understanding

2025-10-27T17:48:00+00:00

Recently it’s been good to see posts advocate working with code as designers to understand the medium, such as this one by Mike Gallagher about designing in code

But there’s a time and place where this is problematic.

When the innovation, the imagination is limited by the designers control and understanding of the medium.

Figma has its own material limits that a designer needs to learn. It’s not free of that and it shifts all the time

Let’s imagine a scenario where you’re rushed against a deadline. Need to create something forward looking that’s more imaginative. But you also need to have something tangible. How things work will often be subtly limited by the designers skill and that time limitation.

So something doesn’t save to database? Who cares … it’s just a prototype. That can be faked.

But what if the limitations in the mind of a designer are their own and not the mediums? What if they don’t get how it works? What if they do but can’t make it work?

I’ve helped so many designers make prototypes work in ways they couldn’t do. Either explaining how things work on the web or in apps. Or by stitching things together to make a vision work that they had paused because it wouldn’t work. I loved helping each designer every time.

But it’s a problem to be aware of. Designing and prototyping in code can mean:

people design unrealistic or limited things because they don’t understand how the web or apps work
people put better designs to the side because they cannot realise them in a tangible way
people miss opportunities or take more time to do so because they don’t understand the medium well enough to do it quickly

Now if you think this is a case for using figma or other “clicky picture” tools it’s not quite. They introduce a different constraint. Which isn’t grounded in some material realism. But really “how well do you understand this tool".

Figma has its own material limits that a designer needs to learn. It’s not free of that and it shifts all the time. Faster than html and the web does. There is also a tax on recreating the platform you’re faking that you often get cheaper with html and CSS (particularly in places with design systems or frontends).

This experience of the medium develops with time and experience. Of making real things with engineering teams or engineers. I’d always advocate to (slowly if needed) get to a place that you can do it in html rather than figma (or other tool).

Happily with AI tools there’s a chance, which again a solid understanding of how the web works, of making and faking things in a realistic manner. Of stretching the “I know this could be real but can’t make it” to “I could reasonably fake it”.

Recently I was able to fake a conversational interaction UI with AI that looked and felt real (but wasn’t because if it was the scenario might not have gone the way I wanted it in the prototype).

Without AI it would have taken me a few hours to set this up. Maybe even a day or so. But it was minutes with an AI before I got close enough I could fly from there.

I still needed to understand the web to ask it the right questions. It was my idea of the flow. I needed to know what magic words to use to get it to give me what I wanted. I needed to know how to glue it into my prototype kit. But what it did do was speed up making my prototype more credible and more provocative.

This took out the time pressure. But it did still rely on me knowing the medium to ask and then implement the code is spat out.

It didn’t directly resolve the deep understanding of a medium a designer needs to develop. But could AI tools also be used to help fill in and answer a person’s specific needs to understand how the web works? I think so, as part of a set of ways of learning.

However, for those designers who want their teams working in the medium and html, the question is:

how do we ensure our designs (or designers) are constrained by the medium and not our capabilities or understanding using it?

Provoking through prototypes

2025-10-04T16:46:00+01:00

Provocotype
Provcatype
Provokatype
Provotype
Pro-
Provoking prototype
Prototypes that provoke

A little bit ago I came across a thread on BlueSky (that twitter replacement thing) about them. But it wasn’t the first thing in the last few weeks where I’d seen or heard it. Ralph Hawkins mentioned them in their weeknotes and returning to a year old one for a new round of provoking and stirring up.

If you haven’t come across the name, you might still have used one or seen one.

A provotype is … a prototype used to provoke a reaction or upset in order to stimulate reflective thinking or new ideas based on that provocation. This sort of prototype is not about usability. It’s not about can someone achieve a task. It’s about provoking a reaction or changing things or turning things upside down.

Italian Radical Design from the 1960s aimed to disrupt how we saw objects, space to push the boundaries of what our lives and living would look like. Creating many provotypes like this red sofa

If many prototypes start with a “what if” a provotype is just a version that dials up the difference and strangeness to 11.

The provocation can be about the materials, the way you think about a concept, how 2 things work together (or don’t).

Prototypes that provoke are common in the fashion industry. Designers will create runway one-offs that are exaggerated, impractical and try to upset normal ideas about things. They build hype. But also try to challenge norms and create or surface new aesthetics. Those ideas get translated into altered patterns. Toned-down silhouettes. And eventually into high street fashions. Going from provotyping to mainstream. From extreme forms and upsetting commonly held ideas or approaches into refined products.

For people doing product, interaction or service design a provotype might just be a vision where AI, data or users do a thing that feels impossible or unlikely. It might switch something from the user needing to prove to an organisation assuming something. It could be bringing in collaboration or other viewpoints in a crucial moment that feels unthinkable right now. Whatever it is, from smaller interface details to services and platforms. It creates a radical “what if” moment.

But before you run off and put on your most garish outfit to try one. I also think it’s important to understand whether you want or need to provoke.

Upsetting or upending or rethinking is not always going to get the results you want. You could probably think of a fair few people you’ve worked with who struggled to work with ambiguity or not being in control. There are some people who provoke and others you bring along.

Some you can’t provoke yet but need to win some trust before you do.

There are people who are welcome to upending everything. And those that do not. I’ve dealt with this situation recently. Having 1 team who love it. And another who cannot stomach anything like that. My current strategy is to get the team who cannot stomach it to create the provocation with me.

I’ve also found that it’s a useful technique to be less ambitious with a conservative team but use that as a provocation for THEM to say what would be more ambitions (ie. show a thing that’s today but a few jumps ahead, but use it to ask them … what would be more radical than this?)

There are also other reasons or situations you wouldn’t want to provoke too hard. Life is tough. Doing research on certain topics, it’s just not a sensible idea. You don’t want to trigger upsetting and dangerous reactions. It’s best to leave those subjects with a more trauma and person-considered approach.

When you show your stakeholder your next prototype with aims to provoke (rather than placate) you’re following in the footsteps of fashion designers. Maybe exaggerating access or ease of data collection. Maybe showing the inner workings to an extreme level of honesty. Or changing how something looks and feels in a way people would never think they could but wished would work like that.

Not everything needs to provoke of course. It’s just another tool in the toolkit.

Footnotes / further reading

Mogensen, P.H. (1994) Challenging Practice: an approach to Cooperative Analysis. DAIMI Report Series. 23, 465 (Jan. 1994). DOI:https://doi.org/10.7146/dpb.v23i465.6938.

Boer, Laurens & Donovan, Jared. (2012). Provotypes for participatory innovation. Proceedings of the Designing Interactive Systems Conference, DIS ‘12. 10.1145/2317956.2318014

Transplanting culture

2025-07-27T19:37:00+01:00

I was watching a documentary a while back about gut health. In it a woman was making home-made “fecal transplants” (Fecal microbiota transplantation (FMT)).

The idea behind FMTs are that you can kick start or change your gut’s system by acquiring the outputs of another. It’s as odd as it sounds. There’s some evidence that it can help in some cases, particularly some stubborn infections.

Cultural change isn’t just a one off injection. It takes serious “diet” change.

Unlike the clinically approved stuff, the woman in the documentary had a blender with some poop in it. She had used her boyfriends and her brothers poop to restart her gut. Made pills out of them. Switching between the two as she noticed different side effects.

One of the influences on our gut health is what we eat and consume. It has a massive impact on our life. Too much junk food then our body optimises for it. And the cultures and things needed to digest more healthy food disappear. But it’s not just food. One of the side effects of antibiotics is that they will indiscriminately kill lots of things. Good or bad. And an encounter with them can really give your gut problems. Diet or drugs, starting a cycle where we can’t even digest or consume the nutrients we’re missing anymore. And then we need significant reboots. Leading to the the need for FMT in some extreme cases.

As I watched this documentary - my wife’s idea I feel I should add - I first thought I was glad I didn’t know this person and had eaten at their house. Watch whose smoothies you enjoy and any second-hand blenders you buy.

Earlier this year I thought about it again. This time when joking around with some colleagues on a particularly tough transformation project. Like a fair few consultancy projects, there’s a fair degree of an organisation wanting a transplant of culture. Not the gut kind (thankfully!) but how things are done, made and rewarded.

The desire being “show us how you do stuff. Join in, be a centre of good culture and we’ll take that and scale it across the organisation”. This all sounds great. But the problem is that most places who want this are too large and too hostile for new culture to be transplanted. And will not pay to keep transplanting the culture.

Cultural change isn’t just a one off injection. It takes serious “diet” change. It’s not something you can borrow, blend up, and hope takes root. It needs a proper change in “diet”. And that doesn’t come from a workshop or a new comms strategy. It comes from what leaders do. And from the people doing the work — who, let’s be honest, have seen this before.

People who have also heard “this time it’s different” a hundred times. They’ve sat through the launch events, the away days, the bold new strategies. And then they’ve watched it quietly fade away when things got hard or budgets got tight. Or had to pretend reorg 2.0 is better. Even though it’s what came before but with a new name.

If you want this stuff to stick, you may have to go slow to go fast. Backing it properly by starting small but with funding. Giving teams space and protection. And without pressure to scale before you’ve got something worth spreading. This doesn’t mean without accountability or being open. It just means not trying to scale across the entire organisation without understanding what it is you’re scaling. And not falling into the trap that you’ll change how things work without work.

It means repeated investment. That means money. And senior leaders changing too. Not just doing what they’ve always done. Not expecting everyone else to change but them. It also takes a lots of people agreeing a destination and process and sticking to it even when it gets uncomfortable. Because the destination is worth it.

But this is where most places struggle. Like a crash diet, they want results by the end of the week. They want faster delivery, clearer outcomes, everyone working smoothly. But the brutal truth is when you’re resetting an organisation’s guts, it often gets messier before it gets better. Things slow down. People get uncomfortable. Your goal will involve some new directions and techniques. And that’s exactly when you have to hold your nerve.

Change doesn’t come from the transplant. It comes from everything you do after.

You're a user but not your user

2025-07-18T17:32:00+01:00

There are many times when you’re building things for people that are clearly very outside your own experience.

I’ve recently worked on a product for probation officers and people on probation. Something I had 0 experience of beforehand (Though as with anything, I love to get into the details and have a greater appreciation and understanding of it). But there are also times when the things we work on we a deep have an understanding of.

Buying things. I buy things. Driving. I drive. Things related to health. I have a mixed level understanding of the parts of health as a user (and having worked in and around health for 10 years lots of other understanding beyond being a user too).

These are more common or commodity things. Things like getting online, shopping, health.

This isn’t just a tech thing of course. Some of the greatest experts are often the poorest judges of the other needs and experiences of people

With those there’s a chance, a good chance you’re a user too.

Personal first and second-hand experience and knowledge can be a powerful factor in helping creating better products and services. It’s why understanding context works. Why people who really know a thing can be so successful in creating new products.

But it doesn’t mean you’re your user.

If you work in tech or IT you’re probably already a different sort of user than another who doesn’t live or breathe digital services. What’s obvious to you may not be obvious elsewhere.

If you know what bandwidth or channel your WiFi router is on, you’re probably poorly placed to assume how people who don’t will understand and act.

This isn’t just a tech thing of course. Some of the greatest experts are often the poorest judges of the other needs and experiences of people. Knowing how stuff is made or the details can be very blinding to how other people understand or experience things. Or learn things.

I’ve lost count of the workshops I’ve been in where a technically accomplished person works on an assumption of their users having or easily getting the basics of a complex subject intuitively.

The answer is of course to develop a deep understanding of other users and note those common patterns. And to share and centre those stories strongly.

Not your own stories or preferences. You may be an outlier.

There are lots of things that annoy me about buying things online. But not all of them at scale will matter. Nor improve how successful an online shop is.

And who hasn’t spent time building a feature to resolve a marketing, sales or senior persons pet peeve or vision that had no relevance or impact on most user’s lives?

Even for passion projects. Unless you are literally the only person ever going to use it, your user is someone like you but not you.

So your experience matters. It can be useful. But it can hold you back or deflect a more important need. You’re a user, just not the user you should design for.

Between shifted and removed costs

2025-03-01T18:07:00+00:00

Many organisations invest in service transformation with the goal to reduce costs or improve efficiency. Be it automating manual tasks, streamlining processes, or cutting out steps that seem unnecessary.

However these changes can end up just moving costs or effort to another part of the organisation or onto users. Leading to new challenges instead of true efficiencies. And ultimately much worse outcomes.

It’s easy to see a task that takes time and assume removing it will create value. Sometimes, that’s true. Like automating how we test whether a change in code has broken a journey. But in other cases, the cost is not removed—it’s just moved elsewhere. Often, this burden falls on users or other teams.

This isn’t always the big stuff. An example I’ve suffered recently is a change in packaging. Over Christmas I was in my local shop to look for some nice beer. I found something interesting. But instead of the usual plastic rings or cardboard packaging, the cans were held together with glue.

A well-designed service should aim to genuinely remove costs rather than just shift them

This likely reduced packaging costs, may have had environmental benefits, and let the product have a clean look. But it also made it more prone to falling apart, and shifted the risk to me as the customer.

I’m sure the team is celebrating cost savings and sustainability improvements. But they achieved this by pushing inconvenience and risk onto me. Recycled cardboard would have worked just fine. Glue, not so much.

I’m not a happy customer when it means your savings cost me more when things go wrong. This will inform every purchase I make going forward.

Beyond beer, nowhere is cost-shifting more apparent than in healthcare. While there are some tasks that are better done with active patients, many health services now place an excessive burden on patients and their families.

Patients are expected to remember their prescriptions, manage drug interactions, and carry information between appointments and teams. Partial digitisation and service cuts mean that clinicians often don’t have the time or access to the right information, shifting that responsibility to patients instead.

The big efficiency, better systems that record and talk to each other, is left undone. So teams are left with smaller ones. Ones where time is cut down to the bare minimum. People are a bag of symptoms rather than a person in the rush to increase throughput.

This means that the most unwell often burden the highest cost of gluing together a good health service. And anyone with a chronic illness facing doing that for the rest of their life. Ultimately at the cost of jobs, money and health of those very patients.

A health service might have saved a bit in efficiency or number of appointments offered. But at the cost of the ultimate outcome: the patient’s health and ability to live a good life.

When we design and build products, if we care about our users and the impact of the “improvements” we make, we need to counteract this.

How might we do that

To avoid simply shifting costs rather than removing them, we need to:

Understand and amplify the voices of those affected and talk with users and teams to identify where burdens are being created
Define the problem properly. Doing root cause analysis can reveal alternative ways to remove, rather than shift, burden
Model the true end-cost. If removing a task leads to more customer service calls or increased churn, factor that into the cost-benefit analysis
Set clear red lines. Principles like “no new burden on the user” or “no added complexity” ensure efficiencies don’t come at the cost of user experience
Work and prototype the bigger solutions. Stop accepting that it’s difficult to share data and start prototyping ways it can be even in smaller sets of services

Successful product, projects and programmes make informed decisions about what they will and won’t do. A well-designed service should aim to genuinely remove costs rather than just shift them. Without this, efficiency gains come at the cost of worse experiences for users and higher costs elsewhere in the system.

Don’t just shift a cost. Remove it.

Service design is not mostly convincing other people to do service design

2024-11-29T14:05:00+00:00

It’s catchy. And many people feel that’s what they do. And you’ll be doing it a bit I don’t doubt.

If you’ve talked to a service designer over the last few years (or been one) you’ve probably heard some variation on that theme. That the job is mostly convincing other people to let them do their job.

It’s a good ear worm but it’s a bad brain worm.

Telling people that’s what the thing is is setting them up to fail. No one wants a methodological pedant who mostly preaches and rarely practices on a team.

No one wants to hear how they’re doing it all wrong by someone who appears to only say that.

Service design starts in the stony rubbish. That’s where things take root. Not in a perfect world where things are cultivated and manicured

If there’s something I’ve seen a lot of the last few years in the service design world, then it’s a lot of pedantry about what is or is not service design. Or how “these aren’t the true conditions” or this or that. And a lot of people trying to do good work spending too much time arguing about what it is rather than getting on with it.

Lots of people following a “preaching and throwing rocks process” rather than getting their hands dirty. Spending time “evangelising” rather than just getting on.

If showing is powerful and telling less so, then it’s about showing how it works. Through doing it rather than talking about doing it. By helping combine various views and helping make better decisions based on that.

It’s done by helping teams visualise and talk about complex things. And be able to add their skill set and viewpoints into it.

It’s done by ensuring teams are held to account by the users actual expectations and experiences. And weaving those viewpoints into business and technical discussions.

Yes it’s hard. But it’s done by doing not telling.

Now people might say, yeah that’s what they meant. But is it what’s happening? If 90% of the work is advocating for service design it must be done by doing. And not preaching and explaining the theory.

If it really is just convincing other people of the approach then it’s a pyramid scheme not a path to better products and services. So it’s got to be mostly about facilitating and designing how services are offered.

Better products and services are made by getting stuck in. Not by disappearing and working on futures that’ll never happen. Or by preaching a set of conditions to do work that’ll never materialise.

Service design starts in the stony rubbish. That’s where things take root. Not in a perfect world where things are cultivated and manicured.

No service design is not mostly convincing other people to do service design. It’s by using tools and techniques to make services and products better. Designing services together. Not preaching about the conditions or what jobs are called.