It might seem obvious, but one of the biggest problems I’ve seen in design teams is the inability recognize an ideation mode of working and an execution (or refinement) mode of working.
Bill Buxton said it best: you have to get the right idea before you get the idea right1.
At the start of your project you should mostly be working in ideation where you must explore a wide range of ideas. Over time you will need to transition to an execution mode and focus on the finest details.
You need to make sure that your team (and any stakeholders) clearly know what mode of work you’re in.
A common approach with agile projects is to add a design spike2 at the start of the project allowing the team to perform enough research for the project to proceed with confidence.
If you can afford it, then go ahead! But for most client-agent projects this will be wasted effort because at such an early phase of the project when so little is known research will need to be broad and difficult to translate into tangible design actions.
The alternative is to learn through making. From day one of a project I encourage you to start making some form of prototype(s!). Show it to people and start learning. Very quickly you will start forming ideas of what you need to learn. This forms the basis of laser-focused research studies that directly contribute to the design of a product.
Understand that during early stages of a project uncertainly will be high. Mistakes will be made and dead ends will be found. Prepare for this uncertainty and make sure that you haven’t committed to an idea too early.
Remember that when working with people cognitive biases3 will apply.
It’s unlikely that any research you perform will have statistical significance so you will need to interpret your results (again it will be difficult to separate your own internal biases).
Your audience is important and a correlation found in one group may not apply to another.
The point I’m trying to make is that whenever you are certain about something, it’s possible that you may be completely wrong. And you need to keep yourself open to that possibility!
A healthy approach to take is to only work with hypotheses4. When sharing research, don’t communicate your results as ‘findings’ but make sure they are seen as ‘hypotheses’.
Findings can too easily turn into commandments in stone. Hypotheses are always fragile and ready to be questioned.
This is the easiest to fix. If you’re designing (and presenting) work as single screens you’re doing it wrong. Always show a sequence of screens in the context of some task. Even better, use a prototype to show the actual steps in action.
I won’t say documentation is waste of time because it depends on the individual project and relationship between team members who are designing and team members who are building5. But it’s important to examine your project and understand where the most impact is coming from.
Are you spending 80% of your time on creating wireframes, comp & specs? or 80% of your time creating a prototype? How valuable are each of these in the creation of the actual product?
A trap I’ve seen many teams fall into is over documentation, where people become proud of hundreds of pages of documentation.
If you’re creating documentation, look for ways to consolidate it so that it’s easier to understand & keep current.
The most important skill of a designer isn’t the ability to facilitate workshops, create assets, or build a prototype. It’s the ability to use critical thinking to solve problems.
But make sure that your critical thinking doesn’t stop with the design challenges. Apply them just as throughly to your tools & process.
We have such an amazing range of tools at our disposal: paper sketching, sketch.app, user labs, A/B testing, style tiles, personas. But each of these tools is only as good as it is used.
Learn to question why you are using these tools, what benefits you get from using them, and what alternatives might be available.
Understand how each tool is used, and how it can be misused. The greatest shame of a designer is when they go through the mechanical actions of some process without thinking why they are doing it. Doing so means you will miss opportunities for discovering even better ways to work.
All designers are essentially perfectionists and will struggle to accept that our work may not be always perfect.
Ignoring this doubt is unhealthy. It makes designers irrationally defensive about their work and unwilling to change.
Doubt is a healthy mechanism, use it as a warning from your subconscious that something isn’t quite right. Examine the doubt to look for reasons that might be causing it, or something you can do to satisfy your concerns.
If you can rid yourself of doubt, have the confidence to continue with the knowledge that any mistakes that do happen are just an opportunity to learn even more.
Remember that ‘agile’ was conceived a software development methodology not a framework for ideation. A spike is a pause in the regular period of sprints that allow the team to perform enough research to better estimate the next sprint. Unlike sprints, no demonstrable work is required at the end of the spike. ↩
Hypotheses are a core part of Lean UX. But remember that any design framework (including this page) are simply a set of hypotheses. ↩
And ideally this distance between designer-and-maker should be as small as possible. If you’re desks are separated into designers and developers it’s not helping. ↩