Design is a promise
When I talk to other designers to ask what draws them to design, it’s usually a deeply held set of beliefs — “I want to make society and the world a better place”, or “I want to make things that are useful and beautiful, that people will get value from”. It’s not just a job, it’s an identity, a deep commitment and mindset as much as a career. When a designer talks about what inspires and drives them, they are really making promises about their work and what it will achieve. I know because I feel this myself — a heavy responsibility to make things better, and make a positive impact on the people and world around me.
I believe design is all about making promises, for example:
- a promise to design a better world and society
- a promise to make your work inclusive, rather than excluding anyone
- a promise to design with, rather than for…
…and countless others, to a variety of audiences. It’s an important concept for designers to align with, that your work is in service to someone, somewhere — and it has to be usable, elegant, inclusive and accessible. But not just your work itself, the way you work also can be designed. I think promises can help frame the concept of designing our collaborations and our work in a more human way.
Promise Theory
I’ve been reading a lot about “promise theory” recently, and realised this is a useful mindset for designers to adopt. Although it’s a theory applied in predominantly technical domains, the mindset can be utilised anywhere. After all, a promise is a concept we all intrinsically understand as humans, and have most likely participated in at some point.
The heart of promise theory is considering the relationships you have and what rules and promises you have for co-operating with one another in those relationships. And this is where I think it crosses over into what user centred design folks do —we make promises about what and how we design for our customers and the organisation we work for
Being able to foster good co-operation is a foundational, game changing skill for designers. In your organisation you most likely work with a wide variety of disciplines (other designers, developers, product managers and owners, senior stakeholders, marketing, and so on) and if you’re lucky, across the lifecycle of a product or service. Thats two fairly complex dimensions for a person or team to deal with at any one time, and to add further complexity all these people have their own requirements, agendas, timescales and other things that we must embrace to make these relationships work.
Promises are a way of designing co-operation
Promise theory asks that we look at each of those relationships, and work out how we currently collaborate. Is it truly collaborative, or are there flaws in the way we communicate, handle conflict, and make agreements on what we will deliver to the people we work with?
We can also use promise theory to frame what we intend to deliver to our customers, be that a product, service or end to end experience.
What can be promised?
A promise is a “license to intend” — for example, “I promise to pick you up in my car by 7pm”, or “I promise to answer your support call within 24 hours”. We can attach agency and promises to non-human entities too, so an electrical socket promises to deliver you a safe and measured amount of power so you can use electrical goods without hurting yourself, and a road sign promises to give you accurate directions on where to go. When we are designing products and services, these things have the same agency attached to them for our customers and users. “I promise you will be fed good food if you come to my restaurant”, or “I promise to supply you with a washing machine that will clean your clothes”. But some promises are much more important, and the consequences more dire if that promise is broken: “I promise to send you an ambulance if you ring 999 to get urgent medical help”.
Most importantly is when a promise is not a promise; when you make a promise it is not an imposition or command. If you are commanding me to pick you up at 7pm (or face some consequences) then this is an imposition, and not a promise, and I might be sufficiently upset by such a mandate that I may break that “promise” by not bothering to turn up. This is such an important distinction to make. What impositions or commands are we asking of our customers? Do we force them to interact with us in a specific way, or via a preferred channel for the organisation, rather than the customer? And when design adjacent practices or teams work with us, what are we commanding them to do when they work with us? (You will do user research, or else!)
Can we change to start making promises to our customers and colleagues, rather than commands? It’s a small semantic shift, but a big cultural change which can bring about hugely positive changes.
Who can make a promise?
We can only make promises about ourselves and what we will do. I can’t promise the bus will be on time to take you to work if I’m not driving it, or that the book you’re reading will be the best one you’ve ever read. Again, the same can be said about the products and services we work on, we can’t promise the washing machine fitter will be friendly, or the ambulance won’t break down.
The experiences we create are strings of promises all linked together
This is can pose a problem for designers wanting to create coherent, successful experiences — which are essentially strings of promises all linked together — when we can only make promises about what we do? At some point those promises are dependant on other people and entities, and that means we need to make further promises between various disciplines to uphold those commitments we are designing into the experience for our customer.
A string of promises for an experience might look like this:
- I promise your password you set will work to get into our system
- I promise that once you have got into the system you will be shown what you were last working on when you last logged in
- I promise the system will have text that is readable for those with sight impairments (and so on).
These are all promises about the experience the customer will get, and framing it like the above means you can start to see where there is a risk a promise might be broken. What don’t you have agency over? Who does?
So what can designers promise?
Designers are in the business of making sound design decisions — or design promises — to achieve the right outcome for the right people. Those design decisions can be viewed as promises that our product or service makes to both the end user and the organisation you work for.
Promises are about signalling purpose through the language of intended outcomes — Mark Burgess
Design is a promise to both the organisation you work for and the customers or users that it serves. For both to be successful these promises must balance both outcomes, and that is the trickiest part for any designer to manage.
Some of the above are promises we can make about the things we work on, but what about the promises we make to those we work with?
As designers we could make promises like these:
- I promise to educate the organisation and colleagues I work with about user centred design
- I promise to provide/hand over designs in a format that aids developers to implement them (Rather than impose a format that is unknown or requires specialist software)
- I promise to provide a documented rationale for why I chose this design to handover
- I promise to engage with stakeholders to understand the business objectives that shape my work
- I promise to adhere to the design principles or standards we have set for our design work
- I promise to base my work on evidence found in user research with our customers
All of these are promises we have agency over, and promises we can keep. In return, we are on the receiving end of promises from those consuming our work. A developer might promise to implement our designs faithfully, for example.
Creating a culture of promises
Requirements are imposed top down, and promises are kept bottom up. Design is a bottom up strategy — talking to users and forming what promises we want to make as an organisation to meet their goal
Starting to use promise theory means we are trying to move the status quo from being requirements driven, to promise driven, and as with all promises (outside of a business context) they must be based on trust and building relationships to drive good collaboration. What promise theory is really asking us to do is enact cultural change, and that is slow, painful and messy work. It is deeply human. But that is where our skills and expertise are: in understanding humans so we can change the culture for the better.
Promises are the uniquely human way of ordering the future, making it predictable and reliable to the extent that this is humanly possible. — Hannah Arendt
I don’t have all the answers on how this should be implemented, but I am looking to re-frame — semantically and philosophically — how user centred designers can view their work. I think it’s an apt theory that acknowledges the humanity required to do successful design, that we must trust each other, and use human concepts like promises to bring that humanity into our work.
If you want to read more about promises, I can highly recommend Mark Burgess’ book called Thinking in Promises: Designing systems for co-operation. It has a lot of the theory that I couldn’t hope to include in a simple article.
