When to slow down a corporate design project? – Valuable Content
There are so many different scenarios a designer can find himself in when starting a new project. Some of them will require fast, divergent actions that will bring ideas to fruition in an instant. However, the problem with that approach is that it has been popularised so much recently, with everything being lean, agile and with weekly design sprints being promoted as the universal way to deliver innovation. And there will be situations, when such approach is hazardous to the outcomes of the project. Slow design vs fast design – how, what, when?
Let’s go through some examples. Obviously, when your project is to make some small tweaks to enhance usability or visual appeal, you probably won’t need extensive research. Here is a TL;DR table for the fast among you:
|Scenarios for fast design||Scenarios for slow design|
|Brochure site||Agency- domain-specific design problem|
|Products built off center strategy||Complex tech or user environment|
|Co-design with the audience||In-house- when careless brainstorming is common|
What do I mean by these two poles?
Fast and furious
Being fast/lean/agile is the thing everybody is talking about now. The way I understand it is an approach when you leverage creativity and rapid prototyping to generate many ideas shortly after the project starts. These ideas are then quickly validated, with e.g. guerilla testing, and this is all qualitative research that you make in a sprint. Going fast usually mean working in iterations, which repeat certain activities again and again. Examples of scenarios which I think are relevant for fast design are:
A big chunk of design agencies’ business is building websites that represent another company, where the focus is on brand appeal and individual characteristics of this business. In such projects, defining the tone of voice and the visual style is necessary to position the brand in the market. The functional aspect is less important, because on websites with small amount of content, users usually cope well with minor usability issues.
Some websites are created to be invisible, and some are created to make lasting memories. Only something delightful and surprising will remain in our users’ minds for longer. Espen Brunborg describes this side of design as ‘comedy’ (as opposed to ‘music’, which is functional and conventional design). Comedy is supposed to give us the unexpected, evoke emotions. By immersing deeply in our users’ world, we can go too far to create something truly unexpected.
That’s why small/medium brochure websites are a great sort of project to leverage design sprints and focus on evaluative research, rather than complete understanding of our users and the business environment. It’s the perfect occasion to utilise our creative resources and build unexpected, unique experiences!
Products built off user centered strategy
When you have the luxury of working for a truly user-centered company, it’s quite likely that there is a user research team. In such an environment, tapping into the generated knowledge allows for the ever-present empathy to propel creativity, meaningful creativity. It’s the best climate for innovative design – because innovation will be rooted in user needs. Google is famous for their design sprints, but they also have a robust research processes around the world and can quickly reach their knowledge resources.
When you have that culture – amazing, innovative, lean design processes are your daily bread. Especially when you have an established design system to leverage. Validation of your designs can also be quite easy, if you have UX researchers and data scientists in the team. It would be a waste to spend too much time before every project, so fast design is definitely a fit in such product teams.
Co-design with the audience
Another great situation to leverage lean, fast design processes is when representatives of your audience are present in the design process. You will have a constant loop of exploration and validation, you develop empathy on the go and tap into the users’ nomenclature every day. It’s best to have the audience to be present during not only the design stage, but also the research (even if it’s lean, it’s still necessary).
While it may be fun to establish rapport with the users you’re co-designing with, it’s important to remember that to ensure the ideas are valid, you should test with different users that you had involved in the design process.
Slower and deliberate
I am a strong advocate of this approach, and I think it’s being mistaken for the cumbersome waterfall processes. It’s not – being slower, deliberate can mean only spending a few extra days to understand the problems we as designers need to tackle. There are simply things that won’t ever be discovered if you start your project from actual architecture or design. You may need to develop deep understanding of the users, the environment and the technology. Nowadays, designers are required to think holistically.
You can user test or A/B test faulty designs that will work perfectly, but won’t be relevant to your audience’s user needs. So even if you create a ‘delightful’ user interface, it may not find its way to your users’ hearts and souls.
Here are three examples of scenarios in which I think the slow design approach works best:
Agency – domain-specific design problem
Imagine a scenario – a CFO of a hospital appoints your agency to build software for nurses. Client workshops you would typically have in the beginning of the project would be conducted with the CFO and other senior employees of the hospital. Without going into a proper user research phase, you would end up sketching out fancy interfaces that might not have any alignment with the actual needs of the nurses. The senior executives don’t spend enough time “out in the field” to pass the knowledge to your team. You, as a designer wouldn’t have time to develop empathy for the end user and would simply lack information or even nomenclature to create something relevant. It would be careless and short-sighted. Yet there are voices in the industry that try to push the fast design approach into any project, stating that exploratory user research is obsolete.
There will be domains so specific, that only proper user research will help you go in the right direction.
Complex tech or business environment
Some organisations are inherently complex. That can be the case for lots of reasons – legacy from pre-digital times or overprocessing that happens, when managers don’t trust employees. For other companies, the very nature of their business is complicated – e.g. banks or insurance companies. UX designers often find themselves being facilitators in these environments, rather than spending 100% of time working on actual designs.
The reason you might not want to rush straight to prototyping is the fact that focusing on one area of, let’s say, an intranet will be a blessing for Stakeholder A, but may be pain in the neck for Stakeholder B. It may seem like a concern for a PM and not a designer, but in the end it’s going to be you redesigning solutions to fulfil everybody’s political agendas.
It’s also important to carefully establish ongoing developments and technical constraints that may arise when tackling a medium-to-large project. What may seem like a small paragraph on your design, may actually mean 2 API calls for your developers and a matter of life and death for the SEO guys.
Oh, and that paragraph may disappear tomorrow because the CEO said so.
In teams where careless brainstorming is common
There are organisations, where new product features are simply brainstormed in the conference room. Thoughts are cheap, but implementing them, and potentially wasting resources is expensive. I was once invited to an internal client workshop, where the facilitator said “Let’s brainstorm our users’ expectations”…
I was in a lot of meetings when ideas flew around like paper planes. My role as a designer then was once again the one of a calculated facilitator that needed to hold the horses, encourage everybody to take a deep breath and focus on the most important solutions.
If I just followed the other people in reckless brainstorming, we would end up wasting a lot precious time going in all the different directions. Building on top of that would be like building a house on sand. At some point it will fall apart.
Have you ever seen a developer’s face when you told him to completely rewrite a feature?
Have you ever seen a client’s face when you told him to pay for the same project again?
As you see, different scenarios may require different approaches to the design process. That’s why I was never a fan of rigid process diagrams, procedures set in stone. I believe that design is such an organic process that it depends as much on the project’s requirements as it does on your team’s setup.
Slow design might derisk a project for certain teams, for others it will introduce new risks. What I think we should bear in mind is that process and philosophy should never get in the way of good design, whatever this means to you.