#47. Newsflash: Your design goals aren't goals.
From the section “Summer Edition” of The Sunday Tales.
The Sunday Tales Summer Edition 2026 will explore topics from my upcoming book. As such, these newsletters will read differently, offering you a sneak peek into my way of working. I hope they will also inspire some healthy discussions!
At the start of almost every corporate project I worked on, a project manager would write a list of goals. Sometimes, the list might be written by someone other than the project manager, such as the company’s CEO.
Regardless of its author, the goals will look something like this:
Redesign the onboarding flow.
Increase conversion by 15%.
Launch feature X before Q3.
Underneath will be written a set of tasks to complete, so the goals will be successfully achieved.
Lists like these become creative briefs. Their contents are repeated in kick-off meetings, and they are also the tools used to measure success after the project is finished. And we call them “lists of goals” because that is what everyone else calls them.
But as I wrote my book, I realised that these are not goals at all. Instead, they are deliverables with a deadline attached.
This distinction might sound like wordy nit-picking at first. But when we think about creating and shipping products that impact real users, things begin to change.
The distinction between goals and deliverables defines the crucial difference between simply designing a thing that gets shipped, and designing with meaning.
In short: a deliverable describes an output, while a goal describes an ideal future state.
For example, “Redesign the onboarding flow" is clear, in that it tells you what to do.
Yet it contains nothing about why that product or feature matters, who it serves, how existing processes should adapt, or what should be different in the world – even a small corner – once it exists.
The onboarding flow of Kialo Edu (concepts). I wasn't sure what should help the user achieve, what transformation. I ended up designing many options based on my assumption!
A real design goal sounds more like this: “People should feel capable and in control from the moment they first open the app.”
Or: “New users should understand the product's value before they need to make a decision about it.”
Now you have a meaning to design for, which may not be an onboarding flow or a screen. It is a deeper state that doesn't yet exist… that your work needs to bring into being.
This is what design must always aim to satisfy.
When burnout brings perspective
I have mentioned this before, but I am in recovery from burnout. I have been doing the basics, or whatever was necessary for me to function as a designer: writing my newsletters (which I enjoy!) and my book, as well as working on a few carefully selected projects.
During this low time, I realised that I was burnt out by a lack of meaning in my work.
I would finish a project and deliver everything on the list, yet feel that something had been missed… the work was correct, but somehow not quite right.
I followed my design briefs to the letter; partly because questions would spark long and discouraging meetings I didn’t have the energy for, as well as losing critical time. But some valuable points were always missing, mostly about the transformation these projects were trying to achieve. As in:
What should be true after this project that isn't true now?
What should someone feel, understand, or be able to do that they couldn't before?
If the design works, how do we measure the impact?
These are not difficult questions. They just aren’t the questions we tend to ask at the beginning of a project, when the pressure is on scope, timeline, and who owns what.
But crucially, they will separate design that endures from design that delivers and disappears, so these are the strategic questions I ask when I work 1:1 with my clients.
Adding meaning to outputs
Most briefs are written by people who focus on what needs to be done, rather than what needs to exist.
Company leaders must protect timelines, manage stakeholders, and translate complex business requirements into definable tasks. This is necessary work, which I would never dismiss. However, this kind of focus means the ideal future state, or what you're actually designing towards, often isn’t defined. We just do the work and hope it will be meaningful. Sometimes it is, but often it isn’t, and nobody is quite sure why.
To remedy this, here’s a simple test I have started using when working with startups.
I take whatever is written as the brief goal and ask: Is this describing an output, or an ideal future state?
If it's something you make, like a website, a flow, a feature, or a campaign, then it is a deliverable.
If it's something intangibly meaningful, like a feeling, an understanding, a new behaviour, or a shift in perception, then you're closer to a real goal.
Goal vs Deliverable. A simple scheme to keep in mind the difference.
Then ask: what needs to be true about the user's experience for this project to have actually worked? Write the answer down, because that is where a design brief truly begins.
This process won't make deliverables disappear. But now those deliverables will have a reason, or a purpose (as I call it in my book), which may encompass different deliverables, actors, and multiple stages of design.
Importantly, you will also know what you're measuring against, so when something isn't working in a prototype or a concept, it will be easier to see why. You get to ask whether you are moving closer to, or away from, your ideal future state.
Goals are harder to write than deliverables (but worth the effort)
They require more thought upfront, more honesty about what the work is actually for, and occasionally, an uncomfortable conversation with a client or a stakeholder who simply wants the list of things to be delivered. They may not know what to do with a sentence about how people should feel, or how their behaviour will be transformed.
But especially in this AI-powered era, having that conversation is paramount for creating projects that have meaning, don't burn your team's energy, and, more importantly, produce better deliverables that think deeply about what they leave behind.
If this piece spoke to you, my workshop Design Brands that Last picks up where it leaves off.
It teaches a smart way to work with AI and to build brands that endure, and still feel meaningful and original.
The autumn cohort is now open, and there are only 50 seats. Join today!