So far in this podcast series we have worked carefully to build a good working relationship with our clients. However, if there is one area that will undermine the client relationship, it is design.
We have all had bad experiences with getting a client to sign-off a design. We have experienced the pain of design by committee, endless iterations and micro-management.
Unfortunately our problems with design approval are not isolated instances limited to the occasional difficult client. The fact that we are regularly coming across issues is an indication that there is something fundamentally broken.
Why is design approval difficult?
The majority of the reasons things go wrong are due to issues we have already discussed in this series. Reasons such as:
- Lack of communication: If we do not communicate regularly and clearly with our clients they become anxious and start micromanaging.
- Relying on personal opinion: Both designer and client feel that their opinion should carry more weight. The client, because they are paying for the site. The designer, because of their experience and training.
- Undefined roles: Many clients lack experience of web projects so are unclear of their role. This can lead to them suggesting design solutions, rather than identifying problems that the designer can solve. This undermines the designer’s role, causing conflict.
- Failure to educate: If the designer fails to communicate best practice in a way the client understands, it significantly reduces the chance of design sign-off.
- No clearly defined objectives: A design can go in the wrong direction if the designer doesn’t have the same understanding of requirements as the client.
- Scope creep: Design approval is often delayed if the project is not clearly defined and there is no mechanism for handling client suggestions. This causes frustration for both parties.
Not all problems with design are directly related to the client. Some are down to our own psychology and way of working. One of the biggest problems is our own pride.
Pride comes before a fall
As web designers we are rightly proud of what we do. We are experienced in building user interfaces, while our clients are generally not.
Despite that they feel justified in criticising our designs and overruling our decisions. This is hurtful and causes us to become defensive over even the smallest suggestion.
However, we must remember that we offer a service and pleasing our clients is a part of the job.
We get distracted by a desire to produce beautiful design to grace our portfolio and impress our peers.
That should not be the objective. Our job is to create effective websites and to achieve that, the client has to like it. If they do not, they will not invest and promote it. It will be abandoned and die.
We need to realign our thinking. Job satisfaction should come from producing design the client loves, not design we (or our peers) love.
We can still disagree with our clients. However, sometimes the right way to ensure a client loves a design is to educate them so they change their minds about what they want.
To do that we need the right relationship and that isn’t going to happen if we disagree with them over every little thing.
When our ego gets bruised by client criticism we can become confrontational. Once in that mindset we argue over every issue that arises, even when we don’t feel that strongly about it.
We need to pick our battles. By only pushing back over things that are important we establish a healthier relationship with the client. The client will realise that when we do speak up it will be important. They will then be more willing to listen.
We cannot allow our pride to turn our relationships into confrontations.
Unfortunately the problem is compounded by bad experiences with previous clients.
Do not learn from the past
It is said that we should learn from past mistakes. Unfortunately when it comes to working with clients we can learn the wrong lessons.
We have all worked on projects where the client has tweaked the design in an endless series of iterations. This is demoralising as the design is destroyed and profit margins are eroded.
The common reaction to this experience is to exclude the client from the design process. Many web designers do this by limiting the number of iterations. Unfortunately this makes the problem worse.
The dangers of limiting iterations
Limiting the number of iterations raises the stakes, making the client more anxious about the design. When they feel that they have to get the design right or miss their opportunity, they are more likely to fret and micromanage the process.
Instead, remove the constraints and minimise the need to approve design. Although some clients need guidance to stop continual tweaking, most will respond better without artificial constraints.
One way to prevent continual changes is to have a clearly defined, collaborative process.
Stop working on design in secret
When we have bad experiences with clients, we shy away from collaboration preferring to work in isolation. This is particularly true for those who design instinctively rather than using a process.
We prefer to work in isolation because we lack confidence and find it hard to justify our work to our clients. We make design decisions on an instinctual level based on years of experience. However, we cannot explain why they are the right.
When a client challenges what we have done, we find it hard to provide a reasoned response and so prefer to limit their opportunities to contribute.
This closed approach creates problems. It also fails to embrace the benefits of collaboration. If we don’t collaborate with our clients, we cannot educate them about design best practice. We also miss the opportunity to give the client a sense of ownership over the design.
When we design in isolation, the design is ours and not the clients. Therefore when we present the design, they feel no sense of loyalty towards it. However if we work closely with the client and involve them, then it is as much their design as ours. This makes them more likely to approve it and defend when reviewed by other stakeholders.
Having a structured, collaborative, design process provides other benefits too.
Using a design methodology
A methodology can be defined as: a system of methods used in a particular area of study or activity.
In other words, design needs to be more than intuitive. It needs to be a series of methods and approaches, which comes together into a system with a proven track record of providing results.
For example, my design methodology at Headscape includes tools such as:
- The business research tools discussed in earlier in this series.
- Discussion around personality and brand
- Reviewing design examples that express the organisation’s brand and personality
- Moodboard generation
- Collaborative wireframing
- Card sorting
- Design concepts
- Interactive prototypes
- Design testing
- Usability testing
The list could go on. We don’t use every tool on every project, but each one has a proven track record of helping to generate successful designs.
How to create a design methodology
The key to a successful design methodology is breaking the process into stages that the client can understand and contribute to.
I recommend splitting aesthetics from content and visual hierarchy. Doing so helps the client focus on what they are making a decision about.
A client may reject a design because it displays the wrong content, even though they like the aesthetics. Equally a solid visual hierarchy, layout and information architecture can be cast aside because the client has a problem with the colour. Addressing these components individually prevents a design from being rejected for the wrong reasons.
Focusing the client on a specific aspect of the design also helps explain your decisions. When trying to explain an entire design it is easy to overwhelm the client.
Think for a moment about the decisions you have to make when producing a design. It is an overwhelming list:
- Visual hierarchy
Don’t overwhelm the client with final design concepts that they have to choose between. Instead split the process into the aesthetics and information hierarchy and explore different approaches in these areas.
For aesthetics produce and discuss inspirational sites, moodboards and personality. Get the client discussing colour, typography and styling. Ask them what kind of personality their site should have. For example if their site was a famous person; who would it be? Produce lots of different moodboards demonstrating different feels and decide on a direction for aesthetics at this stage.
When it comes to information hierarchy and content, arrange a collaborative wireframing workshop where together with the client you can sketch out different approaches to key pages. Include the client in this process so they feel a sense of ownership over the design. You can also educate them about best practice at the same time.
In this post we have tackled design approval, the one subject that strains a client relationship more than any other. I have demonstrated that the answer does not lie in removing the client from the design process, but in collaborating with them. To make this happen you must:
Introduce a design methodology
It is not enough to design instinctively. You must have a methodology that engages and educates the client.
Work with the client on brand
Discuss personality with your clients and use tools like moodboards, inspiration libraries and even posters to work with the client on aesthetics.
Work collaboratively on wireframes
Give your clients a sense of ownership in the design by engaging them in the wireframing process.
In the book associated with this series I talk in more detail about how to work on aesthetics and wireframing with the client.
I also demonstrate that by taking these steps you can ensure that when the client sees the final design it will not come as an unwelcome surprise. Instead it will be in line with their expectations and they will feel a sense of ownership over it.
Unfortunately despite this, things can still go wrong when you present the design and ask for comments. This is what I want to tackle in the final post in this series.