Be a Good Designer, Be a Good Client

Be a Good Designer, Be a Good Client

There has been a lot of talk about empathy with the end user in UX design over the last few years. The importance of understanding what type of product you are building and for whom you are doing it, what needs and knowledge the intended user group has. While this is important, and really hard to get to, there is another type of empathy, that is almost as important during the development of a product and that is the communication and understanding that should exist between co- workers, and between consultants and clients.

Generating ideas: We have (not) already tried that before

Being sensitive during idea generations and brainstorms is extremely important. It takes guts to present half-baked ideas and if they are dismissed in a rude way or too quickly you risk killing creativity in your team.

It’s crucial to vet as many crazy ideas as possible before funneling down the best ones. The essence of idea generation in a team is to allow for a lot of bad ideas to pave the way and give birth to the good ones. When coming up with ideas or solutions, words like “what if” or “I’m thinking out loud” can be helpful to express that design is a process with multiple stakeholders, an ever-changing dialogue and something that is not set in stone but should be discussed.

Try to embrace the fact that you might not have all the knowledge about the users needs or about what might, or might not, work. Pause for a moment and think before you say “We have already tried that before”. Maybe it was not the right time for it at that point, could the idea be revisited in a different way?

Preferences: You not liking something is irrelevant

During the first days of any decent design education you learn that saying “I don’t like this color”, or “I don’t like this layout” is completely irrelevant. Yet we still hear it from time to time. Design is not about your own preferences but about meeting the needs of a specific user group. As a designer, or client, you are (usually) not the user. What you should be saying is – if you know it to be true – “I don’t think this color will work for the intended user group, because…” and that last word is really important. There must be reasons for all decisions in a design, and they must go all the way back to the use case. Also, avoid generalizations. Claiming that “women don’t like this or that” or “men don’t like this or that” is very rarely true.

Expectations and roles

This one is hard, so keep an open mind and be willing to revisit the topic many times during the design process. Who does what, when and why? What is the most efficient division of the work. Every client and every designer has a different view on what is expected from them during a project. Don’t be afraid to speak up if something is wrong. Most misunderstandings can be sorted out by talking and being honest. Don’t hide behind egos, emails or managers. If you do, words will get distorted, misunderstood and issues will get blown out of proportion. Good communication is always key to successful team work.

Be a good client

Being responsive is key. If the designer or developer has questions, try to answer them as quick as possible to optimize their time and your investments. A developer or designer that doesn’t get feedback has two choices; either to wait for your reply, thus being blocked, or continue working on assumptions that might lead the project down the wrong path.

Another important thing to remember is that the developer or designer is likely learning about your field and target audience on the fly. You’re the expert in your field and they’re experts at designing and coding, so try to be patient when they start asking questions that you think have obvious answers. Rest in the fact that they know a lot about their fields of expertise and that with your help they will bring you a great product.

Hopefully you, along with the whole team, understand that it’s pretty much impossible to predict the reaction and use of your product before it’s published. The only way to get a clue is to perform user studies or interviews, but since that takes time it’s tempting to just throw in as many features as possible to cover for equally many scenarios. However, this is often a reason for products failing; trying to do everything rather than doing a few things well. Designers will want to fight off feature creep, not because they are lazy but because they want to create a focused and confident product that knows what its purpose is, that can prove its right to exist. So let designers question your feature requests, but make sure they know what they are talking about. Discuss what the core of the product is and make sure you are not just guessing what the end users need or like.

Be a good designer

Don’t be stubborn with your ideas if they are not crucial to the design. Pick your battles. Know when you are defending good usability and when you are defending your own preferences. If the latter is the case you should be ready to kill your darlings. Consistency in navigation, consistency in how information is displayed and consistency in style is important to police. Explain to the client when a potential change would require a change of an entire system.

Try to think about what a client is really asking for. “The logo needs to be bigger” might make you sigh after hours of figuring out the perfect visual balance on a page but this type of request could actually mean a couple of different things.

The client might be nervous that their name is not going to stick with the user. If you think it will, even though their logo is not covering the entire page, let them know this. Try to explain why something is not needed. Explain the benefits of “less is more”, explain why a small graphical element with a lot of white space can make a greater impact than a huge element with no white space. Maybe the visitor has seen the client’s name five times already, in emails, ads or posts before landing on the actual page. Being a good designer is being a good design teacher, explaining to worried clients why the obvious is not always the best way to go.

Hound reviews Ruby and CoffeeScript code for style violations and comments on your GitHub pull requests. Free for open source repos.