‘Where are we?’ is not only one of my favourite tunes – It’s also a good question to ask ourselves when we join a new product development project.

You know that illustration of the design process as it really is; the one that turns a straight line into a tangled piece of yarn? It’s kinda like that when you step into a new project, trying to work out what the brief is really about and how you can best support the project goals.

It can be quite stressful knowing that it’s up to you to define the design plan but at the same time not be sure about the next steps.

Are the project success criteria clearly defined? Do you have validated and up-to-date user insights? Are there technical constraints you need to be aware of? Is the problem statement even the right one?

I find it useful to take my bearings by asking myself a set of questions when I join a new project. The answers can then help me pin down exactly where we are in the product life cycle and design process, thus informing me of next steps.

My design process – The double diamond

The double diamond has been embraced by the product design community wholeheartedly since it was popularised by the British Design Council in 2004. It wasn’t revolutionary, didn’t introduce anything new and designers had been using variants of it way before it was articulated in its current shape. But it gave us a name and a neat model that is easy to understand and tweak to our needs.

Using this ideal design process as a map for the project at hand, I can use the following set of questions and answers to understand where we are, and thus what we need to do next.

The design process is a model, obviously, and often far from what reality looks like. It may seem a bit too theoretical to be practical in the field but I have found it very useful to give structure to rather chaotic projects – over time it has become the lens I apply to any design brief I’m given.

Questions to ask at the beginning of your new design project

Is this a project? If not sure – Does the project have SMART goals?

Yes: Good, you’re off to the races.

No: The double diamond design process is not the right tool.

In order to put yourself on the process map, the very first thing we need to establish is that you’re part of a project. The double diamond design process is project-led, so if you’re joining a team tasked with maintaining a design system or run designOps, that’s going to require a different process. This is probably quite easy to detect, but if ever in doubt wether this is actually a project, simply map your duties against SMART objectives and if it doesn’t add up your work isn’t project-led.

Do we know what problem we’re solving (or opportunity we’re chasing)?

Yes: At least you’re not in the 1st quarter of the design  process.

No: You are at the very beginning of the process and need to create a problem statement or project objective.

In my double diamond the first diamond refers to product/market fit. Others simply define it as the discovery or research phase. Either way, the first diamond is about answering the WHAT, and the second diamond is about the HOW. That’s a great clue right there and I use it all the time if I’m unsure.

If your brief is “Design this app that is like Tinder for dog owners” you can pretty much rip off Tinder and have a pretty nice design done in a short time. But if the answer was ‘no’ to the question above, you know there’s work to be done in the WHAT diamond.

This is not always what the client wants to hear, but challenging the brief and pushing for a solid product/market discovery phase is sometimes needed and will help the project in the long run. Of course, the client pays your bills so know when to stop being an idealist and find a compromise if needed.

Do we (really) know who we are designing for?

Yes: You can start exploring solutions in the HOW diamond.

No: You are in the 1st or 2nd quarter of the design process and should gather or synthesise user insights.

In our dog owner Tinder example you would’ve been excused for thinking it’s a shit idea. But maybe the product owner hands you some convincing market trends that points towards a real opportunity.

If we don’t know what the USP is (or whether our users actually value that USP), or don’t have a better persona than ‘Dani the dog owner’, you have some user research ahead of you. A design decision should always be a response to a verified hypothesis about your users. This is called hypothesis-driven design and it’s the bee’s knees.

Do we trust the accuracy of the user insights provided?

Yes: You can start exploring solutions in the HOW diamond.

No: You can either redo the user research in the WHAT diamond, or do a mini discovery before you enter the HOW diamond.

Quite often I find myself brought into a project at the beginning of the HOW diamond, only to find that the user and market insights given to me aren’t up to snuff. What was handed to you as a set of personas might’ve been user profiles based on the stakeholders assumptions of the user. What was claimed to be user behaviour based on usage data might not be applicable if you’re entering a new market with the new design.

In this case it’s highly unlikely that you’ll get the time and budget to redo the research phase, but you should at least highlight the issue with missing or false insights and decide best way forward together with your team.

Are all relevant hypotheses about your users answered?

Yes: You can start exploring solutions in the HOW diamond.

No: You can either redo the user research in the WHAT diamond, or do a mini discovery before you enter the HOW diamond.

Similarly to the question above, you might find that after doing a hypotheses exercise you don’t have the answers to design-critical assumptions. Spend some time filling the gaps best you can before going into solution exploration. This doesn’t have to directly include users if that’s too much of an ask. You can also go through customer feedback logs, look at analytics data and talk to stakeholders and subject-matter experts.

Do we know how we are solving the problem (or realising the opportunity)?

Yes: You’re in the final quarter of the design process, with focus on production and testing.

No: As long as you know what and for whom, you’re ready to explore options.

This far into the process it’s usually easy enough to know what’s going on and what needs to get done. Blockers and friction here is more likely related to the designOps in place; i.e. your tools and processes for producing, testing, signing off and handing over design.

---

A good process is paramount for efficient product development. Unfortunately, humans are a messy bunch. When we are put together in large companies with layers of sub-cultures within, we often get a cocktail of conflicting interests, ideas and values pulling the project in all directions.

This is probably why I’m often overwhelmed in my first days in a new large scale project. Things aren’t always straight forward, and we simply have to make the best of the situation and find a way of working that contributes most towards the end goal.

Stay calm, ask questions and figure out what needs to get done. I believe that’s a good way to keep your client happy and your stress levels down.

We all know that the design process can get messy. And that’s fine. Every project is different and need its unique approach for full efficiency. On top of that, every designer has their own preferred way of getting to the finish line. That’s obviously fine too.

There are only really two things that matter when you join a new project as a designer; the beginning and the end. Or in other words – the project definition/brief and the design documentation.

Everything in between; how you explore, iterate and test design is up to personal preference. But the brief and the hand-over are when we, as designers, ultimately have to interface with the rest of the business, so they matter the most.

View design as a tool for the business to reach success. In its most abstract form we’re a black box. We are fed with input and we deliver an output. That’s why it’s so important that we receive the correct input, and we deliver an output that is unambiguous and fit-for-purpose.

Caveat alert, though. I’m assuming that we’ve validated our output in any way appropriate for the project – A/B tasting, user testing, sponsor sign-off or whatever. It should go without saying. We’re designers. We design stuff and hopefully we’re good at it.

The design brief is your responsibility

As a senior designer, this is probably the most important responsibility one can have. Understanding what needs to get done. Challenging the brief where it doesn’t make sense, and shaping it into something you can fully own and support.

More often than not, designers receive vague, incomplete or outright wrong briefs. When I say wrong I mean that inside the problem statement there’s already a solution defined, or maybe the sponsor think they know what they want but the problem space is too narrow.

Watch out for briefs like this:

Add a search button in the bottom bar that opens up a new view where the user can search for tags, users and articles.

This brief leaves very little room for problem solving and prevents the designer from finding alternative, potentially better solutions. A better brief that utilises the designer’s problem solving skills would be:

To increase engagement and time spent in the app, we want our users to explore content generated by other users. How can we make exploring and finding content a key feature in our app?

The correct input will save you a lot of stress

A brief shouldn’t be complete without a success criteria. How do we know when the task is done, or if it was successful? This comes down to basic project management skills, but if our sponsor doesn’t have them it’s up to us to bring it to the team. When you start out there will be a lot of TBCs and known unknowns. It’s the unknown unknowns you have to look out for.

If the project sponsor briefs us on a new app design, it’s up to us to enquire further until we know the OS in mind, how they reached confidence in the value proposition, what markets they intend for launch and later, what accessibility standard they’re OK with, and so forth. They might be unknown unknowns to the sponsor, but they are known unknowns to us and we need to make them known knowns for everyone involved.

I don’t know about you, but personally I do my best work when I have a clear path ahead and can focus on the task at hand. This is what a clearly defined brief does for you – it allows you to write a step-by-step plan for the actions you need to do to deliver the desired outcome. As a strong Meyer-Briggs J it gives me immense satisfaction to have a plan in place, but I’m pretty sure that P’s can benefit from this too. On the flip side you risk a lot of stress, shilly-shallying and busywork if the brief is unclear.

Examining, co-writing and defining useful project briefs is without a doubt one of the most useful and important skills a designer can acquire. It’s a soft skill that comes with experience and involves pattern recognition, a good understanding of product development and good people skills.

An output that was ambiguous and unfit-for-purpose

The deadline for submitting the app was fast approaching. As a sub-contractor I had been asked to review the GUI and highlight usability issues and areas for improvement.

Together with some quick fixes to the app’s usability I included a few scamps of future direction – A concept thrown in for added value and food for thought. The day after I received an email:

The client loved your new design. Can you make a few changes to it and send me the designs? They’re including it in the app.

As a concept, made to inspire and explore avenues (*cough* and secure more work for me *cough*) it was fine. As anything even remotely intended for production it was textbook poor design documentation. There were heaps of ambiguity, details missing, logic not fully thought through, and as a design specification it was completely unfit for purpose.

It wasn’t the first time someone took a concept as production ready design. This is what can happen when you don’t work directly with the product team, and when it does you usually have two options – take the money and run, or stick around, brace yourself and start educating. But that’s a topic for another time.

How I document design

The best output for design normally happens when you work closely with the receiving end. If you’re part of the product team you can sit down and together define exactly what they need from you. Personally I’m a fan of light documentation with tight version control.

I’m mainly talking about production ready product design, documented for business analysts and developers. But design deliverables can obviously be design concepts, user insights, pattern libraries etc. Documentation for these are just as important, and the general rule still applies: Make it unambiguous and fit-for-purpose.

For production design I usually split form and function into separate documents. The form specification would ideally be a UI library, design system or other type of component-based repository. Pure form and standardised states and interactions.

The functional documentation explains all the feature specific logic, user journeys and edge cases, and requires bespoke annotations. For this purpose I prefer a less strict format and usually go with PDFs created in Keynote. Version control and change logs are manual, and there are probably tools out there that can make this step more efficient, but so far I haven’t found anything else that gives me the freedom in layout and format that this type of documentation normally requires.

With these two documentation types we have two sources of truth that don’t interfere with each other. The functional specification can use wireframes, scamps or anything in-between as long as the logic described is accurate. In reality we often end up with a middle ground and use tools like Zeplin to specify final page designs. This is fine but does require more maintenance and work.

A final tip

Keep a journal with all decisions made along the way and the rationale for making them. Include decisions made by you, collaboratively as a team, or by stakeholders with mandate. This way you are able to backtrack from final design all the way to initial concepts and trace it back to the design brief.

It could also be a good idea to include some of the high level rationales in your official documentation to help the receiving end understand why things are done the way they are.

In his book Drive, Daniel Pink lists three things you need in order to be content at your workplace:

Autonomy, mastery and purpose.

After ten years in product development I had carved out a pretty decent path for myself. There was no shortage in opportunities to practise and improve my skills. As a senior consultant autonomy was usually given to me as well. But as you may have guessed by the title of this article, I had a nagging sense that I was lacking purpose.

As Pink pointed out in Drive, you need purpose to feel completely content at work. Quite likely this doesn’t show until you’re a few years into your career. As a junior my focus was on mastery. As a mid-weight I got obsessed with Autonomy (which eventually made me quit my perm job and start freelancing). Eventually purpose caught up with me and asked why I should care at all – How was I contributing to a world that I wanted to live in?

Purpose comes back and bites you in the ass if you don’t deal with it sooner or later. Around this time I was reading Robert Greene’s book Mastery and realised that I could never become a master at anything without believing truly and passionately in the cause.

Listen to anyone who’s really good at something talking about that thing. Quite often they describe it in abstract, almost poetic ways. What they’re doing is no longer a concrete craft, sport or skill, but a manifestation of the cause behind it.

Finding Find your Why

After trawling the web for guidance, mainly finding abstract, generic and new-age infused tips on how to find purpose in life, I found a book that sounded like the real deal:

Find Your Why: A Practical Guide for Discovering Purpose for You and Your Team

After reading too many ‘Follow your heart’ blog posts, this ‘Practical Guide’ could maybe finally get me somewhere. This is the follow-up to Start with why by Simon Sinek. That book brilliantly turns the traditional business model on its head and explains why the world’s most successful companies operate with a deeper purpose (aka the Why) at their core and let everything else follow.

It’s easy to buy into the arguments listed in Start with Why. It’s apparently harder to apply it in real life since they had to write a how-to guide for it.

Find your Why can be applied to individuals as well as companies and teams. Without hesitation I bought the book. This is what I learnt from doing the exercises in the book.

Finding my Why

The book I used to find my Why spells out step by step how to do it, both for individuals and teams. It also helps you define your How.

If you’re not familiar with Sinek’s Golden circle model, this is how it works:

The Why is our purpose. It’s the reason we get out of bed in the morning (or should be at least). It’s based on our core values and are thus not likely to change much with time.

The How is our personal execution style. How we approach life. Facebooks’s How for instance is ‘Move fast and break things’.

The What is what we do every day. For a company it’s the end product or service. For individuals it’s our job, or other activity that supports our Why.

What events in your life shaped you?

The process for finding your Why as an individual starts with thinking about your past and identifying the most impactful events in your life. Events that shaped you as a person. You go back to these because they clearly mean something to you, and a lot can be understood about your core values by hearing about them.

You look for experiences and people that did any of the following:

• Shaped who I am today
• Helped me become who I am
• Taught me something
• Made me proud
• Were painful or good, as long as they shaped me
• Has an emotional connection

Finding these really important memories is not an easy task. Even when the book guides you through this exercise with pointers and things to look for I still had to dig deep, often questioning the importance of the stories I found.

This is a very personal exercise and some might have no issues at all identifying these character shaping stories. I had a rather normal upbringing, so my stories reflected that I guess. But in the end they were all relevant and emotionally loaded on a very personal level.

Once you’ve found a number of stories, big and small, next step is to share them with someone. You need to find a person who doesn’t know you well enough to be biased, but someone that you feel comfortable sharing these personal moments with. This person has a big responsibility in listening carefully to your stories, taking notes, and finding common themes in them. This could also be themes in the language you use when you tell them.

I chose my partner Laura to help me since I trust her completely, but at the time of doing this exercise we had only been together for about a year and a half so most of these things about my past would be new to her.

I had my own idea of what themes might emerge from all this, but allowing Laura to feedback what she had captured was very useful. Not completely different, but more nuanced, and definitely less biased.

The most important themes we found were these:

• Stand up for yourself and your beliefs
• Love for what you do
• Enthusiasm
• Freedom
• To question and challenge
• Being part of a group

Creating your Why statement

From the newly detected themes, some will stand out more than others. The next step is to shape your Why statement based on these themes.

The Why statement follow a template which makes it a bit easier to think about. It also has to benefit others in one way or the other. This came to me as a surprise at first. What if you’re a hermit, or hate people or only want to help animals?

But this is where you have to trust the process. Sinek and his team have dealt with hundreds, if not thousands of people and found that this is one of the fundamental requirements. Other sources claim this to be the case as well. We are flock animals after all.

The formula:

To [Contribution] so that [Impact].

It takes some time to get this right. This is your Northern light after all. The only one thing that matters in the end. Your calling. So, no pressure.

You can always tweak it over time, just to get the wording right.

So why do I wake up in the morning?

To inspire people to challenge themselves so that they can live with intent.

That’s it. I can own it 100%. This is what I want to do with my life. It’s what makes sense to spend my time on, one way or the other.

Finding your Why shouldn’t come as a total surprise to you. I think you can feel it when you get it right. It simply resonates with you.

As an adult I’ve always had a beef with people living on auto-pilot, not challenging themselves in any way. Because challenges make us grow, and growth is good. So for my Why to be about making people challenge themselves to become better, happier and more fulfilled made immediate sense to me.

Adding your How

As a bonus you can also work out a set of How statements based on the themes you found earlier. These are probably less critical but are still useful as reminders in your quest to be true to yourself and become the best version of yourself.

Using the themes again you’ll find around five principles or guidelines for how you approach activities. They should be:

• The ingredients I need to be at my best
• My strengths
• Simple and actionable
• What I do to bring my Why to life

In my case I formed these How principles:

Bring the joy of being alive into everything you do
Embrace the task and make the journey the goal. If you can’t be enthusiastic about it; don’t do it.

Own your actions
Assume autonomy. Do what you feel needs to be done and take full responsibility of the outcome.

Enjoy exploration with an open mind
Exploring is fun, but only useful if you’re open to changing tack based on what you find.

Use the knowledge of the group
Include everyone, foster idea sharing and encourage feedback.

And then What?

So I found my Why.

Now what?

The What can be anything really. It’s just the manifestation of the Why, so in my case I need to find a way to inspire people to grow.

As a freelance product designer that’s easier said than done if I want to incorporate my Why in my career. Which I obviously want since the whole pursuit for meaning started as a result of not finding it in my job.

At the same time I don’t want to leave product development for something completely new. I thought about this, and the best thing to do would be to create a product or service that supports my Why.

That’d be awesome. But I don’t know what that would be. Yet.

The second best would be to join a company that shares or supports my Why.

That’d be sweet. If I find one it’s definitely an option.

The third best thing would in theory be to become a manager and inspire growth that way. But in practise it’s not really for me. Never had the urge to manage people. Mentoring could be an option.

And finally I could find meaning at work by giving and helping in general, as explained in the book Give and Take by Adam Grant.

I did this exercise two years ago. I’m still lost. I know my Why and I know that although contracting for various clients is stimulating and mostly great, it’s not supporting my Why.

And as we noted in the beginning; without the Why, we won’t reach full potential, nor fulfilment.

So the pursuit continues.

“Are you UX or UI?”

The recruiter that sat across the table was dead serious. From a recruitment standpoint it makes all the sense in the world to profile your database of job candidates.

I have to admit I was taken aback by the question.

This was back in 2015, and UI designer as a job title had only just started to emerge. The UX designer title had already existed a few years, often paired with visual or graphic designers to cover the full spectrum of user interface design.

So here I was, being asked the cryptic question wether I was UX or UI. X or I, Experience or Interface. Red pill or blue pill?

When the UX title started to spread and I came across it for the first time my title was interaction designer, and the title fit the role well. I was designing interactions users were having with interfaces. So I was also, per definition, a UI designer.

I always considered myself being a designer for interfaces, even when my title shifted to UX designer in 2013. So to be asked in 2015 if I was UX or UI didn’t make sense to me. I was both. The industry had given me the label UX, but as part of the X, I obviously had to consider the I.

So to the recruiter I guess I was UX/UI. Someone who wants to emphasise their visual design skills would be UI/UX.

The problem with UX and UI designers

The problem with splitting these two tightly knit terms into separate buckets of workload is friction. Friction that comes from misinterpretations, treading on toes and doubling up work.

A very common team set-up consists exactly of this designer pair. A UX designer and a UI designer of same seniority are supposed to cover the full spectrum of product design. First we do the UX and then comes the UI.

This sounds ridiculous when you put in black and white, but I hear it all the time.

“First we do the user experience.”

What is referred to here is the translation of requirements and insights into user journeys and page layouts. Possibly interactions too. What’s left to do is applying brand or styleguides. For an already established product this is sometimes derogatorily referred to as colouring in the lines, or “make it look pretty”.

This is all wrong from a team structural standpoint, and it’s a result of confusing and misleading terminology. I can see why we moved away from using ‘interaction designer’ to encompass the duties of a UX designer though. User research, product strategy and service blueprints were all done by us but didn’t get reflected in the title. We did so much more than interaction design; we considered the whole customer life cycle – We considered every aspect of the experience!

Information architects, human factors, interaction and UX designers have always been on the more science and evidence driven side of the fence. They were not the go-to people for typography, iconography and visual harmony. The artistic and creative flair was left for the graphic, or visual designers.

While they still thrived in agencies doing plenty of conceptual and exploratory work, with the rise of systematic design in recent years there were less need for a team of graphic designers working on an already established product suite. The UI designer role was thus born from graphic designers with additional skills in HCI and behavioural psychology.

Where do we go from here?

I’m going to talk about team structures in another post. For now, I only know that UI is part of the UX. Whatever we call ourselves, the UX/UI split is not a good way to define job roles and responsibilities. The overlap is too big, the responsibilities too vague. We need new terminology to get us away from the catastrophic confusion that has built up over the years, mainly due to the UX designer title.

UI is a thing. UX is also a thing. But UX designer? I think it’s time to scrap it. UX is affected by every part of the business, and to put the responsibility to design it into one single role would be stupidity (unless it’s the CEO).

More and more we see the role ‘Product deisgner’ taking over. This seems to be a visual designer who also understands user psychology and business strategy. We also see niched UX:ers in UX researchers and UX writers.

For UX designers less adept at visual design or not willing to specialise, don’t fret – I think we should find a new identity in the domain of the architect. I’ve been playing with variations of this. ‘Systems architect’, ‘UI architect’, or maybe ‘Product architect’.

Design is a very powerful word. It comes with a set of preconceptions that hardly will go away. We need to pick our battles wisely and maybe realise that as long as we call ourselves designers – UX, UI or UX/UI, people outside our industry will assume that we deal with the look and feel of the final product and that only.

Let’s mull it over as industry practitioners and see what we can come up with.