At the core of design is a deeply intellectual, methodical, and innovative process.
The truly great designers do not simply 'master' their craft. Mastering implies a set of defined rules and techniques for which you can achieve a high level of proficiency.
For that reason, I sometimes don't like the word mastery. From my undergraduate and graduate school research days, one of the things I loved the most about the academic environment was the ongoing commitment to forging new paths. It was not enough to simply learn the techniques in the textbook and then deploy them flawlessly. That's fine and dandy for solving homework problems and copying examples in the textbook.
But not for discovering groundbreaking research.
What really sets graduate PhD research programs apart from other programs is the experimentation around experimentation. Research methods and studies are always being developed in novel ways to do several things:
People often mistake design with its more expressive, soul-searching cousin - art. (I'd argue there's probably also a process involved there as well, but I'm not an artist.)
However, designs get better due to more rigorous and interesting methods of discovering answers and translating those answers into prototypes, products, etc.
For this reason, an important step here at my design lab is to approach design and process much like a research professor would. I learn about commonly used methods, explore the limits of those methods, and then devise new techniques for discovering deeper insights.
A masterful senior designer can take you far. But a trailblazing, nerdy designer trying to be Einstein may take the work (and the field) to a whole other level.
You're sitting in front of your computer.
You did user testing. The points of confusion are so obvious.
You research. You ideate.
One 'aha!' after another, you feel like freakin' Jony Ive designing the first iPhone.
The design. So simple. So elegant. .
It's 2PM. Time to meet your product manager.
You open your laptop to show your latest breakthrough. You sit back and say, "Before I walk you through my changes, I'll let you have a look at it first." You lean back in your chair, and wait for the praise to come rushing out like froyo from a machine with a stuck lever.
Instead, your PM is squinting at the screen. "Am I supposed to click here first?"
The folds in her forehead start to become prune-like.
It was the most agonizing 5 minutes ever.
What went wrong?
20 Minutes Later
"I really like where you're going with this."
Of course, now I'm feeling smug.
For many junior designers, this situation is extremely common. (And I'd venture to guess that even the most seasoned design and product professionals experience the same situations, from time to time.)
Seasoned designers learn to deal with these situations throughout their career. It is during these times that designers show their maturity and potential.
People don't get your design because you may be acting like a less experienced designer. Often, Inexperienced designers focus on being right for the wrong reasons. They have egos. Their emotional investment in a design is proportional to the amount of time they spent on it (and how smart they think they are). They care about being right because they are insecure.
Experienced designers focus on proper communication. Experienced designers don't care about being right - they care about getting to the right answer. Big difference.
And in order to get the right answer, they use any and all opportunities to discover the blind spots in their work. And here lies the difference in the mental models of junior and senior designers.
Let's return for a second to the topic of this post. "Why don't people 'get' my design?"
For the junior designer, the answer to this question is simple. It's not me, it's you.
For the senior designer, the starting point is, "It's not you. It's me."
Designing a web application's UX/UI is always a beast.
When you're designing websites, you should start with the content.
When you're designing for web apps, the content is often data or the result of data analysis. Even a small snippet of data that is unaccounted for, can be enough to sink a UI.
On a recent project involving the design of an optimization feature, there are multiple moving pieces. You have data scientists, developers, product managers, and of course me, the UX/UI designer.
During an agile sprint, the designer is prototyping, wireframing, etc. The data scientists are constantly changing and tweaking the algorithm. The product manager is doing a million things. After several weeks, the UI was coming to a close.
And of course, there was a variable that we did not account for. The engineers hadn't gotten to the part where they were working with the API for that data, so no one talked about it that frequently. Of course, it's never just one piece of data.
It was the most complicated piece of data, stretching the limits of the current UI, to the point of breaking it.
Of course, there wasn't much to worry about. You just have to go back to the drawing board, add another constraint, and come up with an even better solution.
Don't forget. Content first. Data first.
As designers, we're often looking for design validation - some response from the world that our design is 'right'.
We show our design work - even designs in progress - and hope that whoever sees our work will show a glimmer of delight and tell us how creative we are.
Instead, the people who see our work often respond with, "Hmm, well how about this? Why didn't you try that?"
And our blood boils. And we think to ourselves, "How dare they question my design? MY design?!"
Let me stop you right there.
The people giving us feedback are doing us a huge favor. They're exploring options that we hadn't considered (or options we considered and dismissed). This expands the range of solutions, which may or may not be better than what we have created. But it's our job as designers to either filter out these solutions or explore them.
Only in doing so can we find the optimal design solution.
Sometimes, a complicated story.
Enterprise software is a beast. A unsexy unruly beast.
Sometimes, you go back into the platform to clarify some copy due to changes in the system. At the same time, you find some opportunities to clean up the UX and make things a little clearer for the user.
Of course, the director of product management then gives a one hour presentation on the feature and how it works. And then you realize it's not so simple. (Of course, it never is. Even when you want to change some copy.)
Today, everyone is telling everyone to listen to their users and customers.
Following this rule at face value is a disaster waiting to happen. Especially among beginner UX designers (or any innovator/creative for that matter), this can prove quite problematic.
Getting out of the building and talking to people is really only the first step. This step is data collection. Beginning researchers and designers conflate data collection with data analysis.
For example, in an interview or usability test, a participant might explain why they hate something. Or they might even tell you with logical explanations what font color needs to be used or that they don't seem to understand something.
Beginning designers might construe these comments as an indication that some element X of their design is confusing, and thus needs to be 'improved' based on the user's feedback. However, most of the time, this is the wrong thing to do.
First, your user doesn't understand that interfaces can be learned.
Secondly, your user doesn't have access to the same data that you have or will have.
Third, your user also has a bias of their own.
New designers try to overcome their own bias by hoping that other people's opinions will balance out the bias.
However, expert designers approach this differently. By talking to others, their aim is to discover flaws in their own reasoning, the reasoning of others, followed by analytical processes to decide whether their design really needs to be changed or tinkered with.
What does simplicity actually mean?
I haven't yet read any formal definitions, but here are some early thoughts on what I think it might mean.
One might think that simplicity might be synonymous with minimalism.
However, I'm not sure that's the case. I also don't define minimalism to mean anything other than good use of white space, reducing noise, and using more elements than is needed. I've seen sites that are minimalist.
But I think simplicity has an added touch.
Simplicity has an element of elegance to it. It evokes a real effect on the user or audience.
I was designing a screen. It didn't have a whole lot of text. Probably could fit the definition of minimalist. I actually added an icon to the interface (rather than taking something away) and it made the interface feel lighter. My brain actually felt like weights had been taken off of it.
Then I replaced one line of text with two icons. (Sounds kind of odd without giving you the context.) Again, also adding more things (while taking away one line of text).
Amazingly, I could comprehend the interface faster. I put the two screens side by side, and the difference was astounding. When I looked at the revised interface, it was hard to describe what I was experiencing.
But it felt simple. And that was enough for me.
Could simplicity in fact be a feeling?
On a recent design project, I spent quite a bit of time sketching. They weren't fancy.
I just used plain printing paper and a ball point pen (wasn't even a nice one).
The primary purpose of the sketches was not to show off my sketching abilities. It was the fastest skill in my tool box for rapidly generating ideas and exploring them in detail.
Given that this is my purpose, any other 'improvements' to my sketching process should not slow me down or make me more 'attached' to my ideas. This is often the case when we start to make things look more real than they actually are.
Thus, I am simultaneously amazed yet wary of sketches that look like they should be framed. The kinds of sketches that look like they were produced by architects. This is not the road I want to take.
Any skill can be improved, and should be improved as long as you have a reason for it. I'm thinking of giving my sketching process an upgrade. At some point, I may want to show users or product managers my sketches. The better they can communicate my point, the better off I'll be. However, these upgrades are probably more like supplements.
I'll still retain my original sketching process, and create more refined sketches when I need to show them off to people.
Here are some links that I've found interesting or useful:
How to draw quick useful UI Sketches - Lane Halley
5 Big Tips for Sketching on Paper
Sketching User Experiences - Bill Buxton
Have a favorite resource for learning how to sketch? Let me know below!
Design myopia is a term I've coined for moments when I've spent too long on a design problem and get stuck. Once you've worked on a design for too long, everything starts making sense to you. After more than 3 weeks working on a project, it's likely that you have a hard time finding the weaknesses in your design. (especially if you've made it this far and have already put it in front of other people's eyes)
Design myopia is really a serious issue. As you get to the final 10% of a design, you can easily spend 25% of the total project time tending to these final details.
Some common psychological issues that arise toward the end of a design is the fact that you feel like an expert. If other people are confused by some small details in your work, it's because they don't think like you (you tell yourself). They haven't spent as much time as you have on this project, so they just don't get it.
In these situations, it becomes imperative that you don't continue forcing your way to a solution. In one instance, I walked a colleague through my screen flow and explained areas where I had been stuck. I explained the precise parts that users had experienced some confusion. Within 20 minutes, my colleague made a small change that I hadn't considered and helped me get to a more elegant solution.