Not everyone is a designer
This may seem obvious, but not everyone has design skills and talent. It doesn’t matter which aspect of user experience (UX) we’re talking about, not everyone can do it. Most agencies have a process in place to assign tasks based on skills required. Good agencies are capable at managing external clients, setting expectations, requirements, roles… and enforcing them.
When the client is internal to an organization, sometimes the lines can be blurred. A good process prevents conflicts. Without such a process, occasionally the client can attempt to be the designer.Â
Business Analogy
To point out how odd having non-designers design can be, here’s a couple analogies. First, let’s say you’re the internal client or otherwise in charge of the business goals. Someone comes to you with the success story of Colonel Sanders, citing changes you should make based on his success. Obviously fast food has become very popular, therefore the lessons learned by the KFC founder in the 1930’s are perfectly applicable to your business of converting desktop applications to mobile applications. For example, Sanders’ first restaurant was in a motel. Therefore, your company should start opening up sales offices in motels across the country. Next, your business should join the Rotary Club because Sanders did too.
You’re probably going to look at this person like they don’t have a clue. The Rotary Club? Really? There, now you have an idea how designers feel in these situations.
Dev Analogy
If you’re a developer, imagine if someone came to you and said “I like how Site A works. I hear it’s built in classic ASP – can we build our site in classic ASP too?” Fortunately, that doesn’t happen with development. In design, this likely happens because of the misconception that since it’s visual, anyone with eyes can solve the problem.
Design is much more of a science than most people think. It’s closer to code than art. Imagine you wrote an app and someone came in to review it. First, they changed all of the syntax highlighting to “prettier” colors. Then they started adjusting the formatting so things were aligned to their liking. You might be a little irritated, and think it’s all a waste of time. Then they start making more changes – they’re not a fan of curly braces so they change those all to square brackets. The app breaks.
“Well, you get what I was going for so just do your thing and make it work again…”
In dev, that bracket change doesn’t work because the syntax requires curly braces. The syntax is chosen based off of the stack. The stack is part of the platform and its architecture is an overall “pattern”.
In design, that bracket change doesn’t work because it breaks the design pattern. While the change in design doesn’t result in an error printed in the browser that everyone can see, in design such changes can easily conflict with the goals of the design.
Good designers won’t work like this
So what happens to designers when they’re relegated to the role of user interface janitor? For entry-level designers, they’ll probably stick around for a while. For experienced designers, they’ll either check-out and become apathetic, or they’ll leave. And then some designers, who may have held the job for a while, might just go with the flow. They deliver what’s asked for and not what the user’s need.
Capable designers do not like to clean up other people’s messes – especially when they’re not allowed to properly clean up, but just rearrange the mess to something less bad.
If you ran a restaurant and the chef was constantly burning food, would you expect the assistant to fix it and make it better, or would you find another chef? No one wants to be the assistant fixing messes, especially when the assistant is more qualified to begin with.
So what’s the answer?
One of the first steps to having a better understanding of design, is to recognize that designers are not artists. UX design should be delegated to those who are skilled in UX design. Delegation is key. If you can easily answer the following, you might have a good enough idea of what design is to help make design decisions or choose who to delegate to. Depending on how you answer these questions, you may need to find someone who can delegate for you.
- Describe the differences between:
- Information Architecture
- Interaction Design
- Visual Design
- UX Design
- Do you use terms like “coolâ€, “sexyâ€, and “sticky†when defining what the success of a design looks like?
- Would you use a Focus Group in your design process? (Inspiration from uxmastery.com)
- Do you know what HIG means?
- Where in the software development product development lifecycle should design start?
If you can’t easily answer 1, 4 & 5, then there’s a high chance you shouldn’t be making design decisions. If you answered “yes†to 2 or 3, then there’s even a higher chance you don’t have what it takes to delegate without help. And if you didn’t put design somewhere near the beginning in your answer to 5, you really need to surround yourself with some UX expertise. Keep in mind this little quiz is not about who should design but who is capable of delegating design. What it takes to be a designer is a whole other issue.