This article is a collection of simple rules that I use to dictate my design practice. I present it here not to be prescriptive but rather to inspire others as they build their own practice.
Talk to people
Users, customers, team members, investors, bosses, managers, and stakeholders. These are all names I give to people with a particular role in the design process. However, they are just people. Nothing more. Nothing less.
Once I embraced the idea that these are not mysterious, influential individuals who can catastrophically control my future, I found that the idea of talking to people is the best part of being a designer.
I can learn from everyone.
Learn, scope, shape, build, learn
We designers like to think that the design process is a mysterious, ever-changing thing. I have found that the more I can simplify my design process the more I am able to iterate and make decisions quickly.
Learn
The act of using outside information to inform my decisions. Learning comes in many shapes and sizes. Sometimes, it’s having frank, curious conversations with people to uncover behavior, fears, and motivations. Sometimes, it’s digging into scientific papers or analytics dashboards to uncover problems or needs. And it is often reading articles, journals, newsletters, and more to understand the intricacies of a particular industry or problem.
Generally, conversations with people will reveal compelling stories and micro problems. Data, papers, and articles will reveal macro-level problems and support (or refute) compelling stories.
Scope
Figure out the problem, the goal, and how much time I have to build it.
Shape
I think of shaping as translating and clarifying. Spend time learning, and then figuring out the problem, then it’s time to understand the shape of the solution. This isn’t necessarily the solution itself, but rather the structure, flow, and system that will make the solution.
Immerse Yourself
To truly understand an industry, problem, or need – immerse yourself in the publications, media, and hang out spots of your user.
Interfaces are words
Until the time of universal icon sets, words make up much of the interfaces we use. This means that understanding words and everything about them is crucial. Grammar and spelling are crucial to communicating to users. The language and voice that I use will create continuity, build trust, and shows a commitment to the user.
Additionally, understanding typographic hierarchy becomes incredibly important. When most of the things we see are words, understanding how to master the typefaces I use and how to use them to their fullest potential to communicate to the user properly.
Colors are important too
Colors have three primary purposes when designing products. In a particular order, to indicate system state, to create hierarchy, and to convey emotion.
One of the benefits of the commodification of UX design by the likes of Big Tech is that the public conscious (at least in the western hemisphere) understands colors used for system state. Red for error, green for success, yellow for warning, and blue for links. This means that these problems don’t need to be solved over and over except in highly specialized situations.
The other two options, hierarchy and emotion are where the designer can spend more time exploring, iterating, and pushing boundaries.
The primary downside of the commodification of product design is that many of the interfaces we use look the same. Many designers spend little time thinking of their color palettes and how to use them to create clear, understandable hierarchy that conveys a particular message to a user. The realm of graphic design spends many hours teaching, training, and developing a sense of color theory in its practitioners.
Users are people
Don’t refer to users as users. Users are people who are doing something with my product or brand. Referring to them as people reminds me of crucial shared context about who they are, what they need, and what their goals are. As an example, Duolingo calls their users learners.
Don’t “allow” users to do anything
When framing the purpose of a particular feature, avoid the word “allow.” The word “allow” conveys a passiveness that should not be present in intentional design. If I only ever allow my users to do something, I miss a significant understanding of their true goals. Typically, when describing my work, allow slips out as a lazy or uniformed description of the true action.
I should approach every problem as if my tool were the last thing my user wanted to use. They use my tool because they have few or no better options. This moves my mindset from one of passive “allowing” to an active participant and partner in their goals.
Be yourself. Always.
No further explanation required.
#personal #blog
