Ooh, I’ve been doing nothing but this for 30 years. There’s other good advice in this thread, but my main advice is to pay close attention to people. UX is just applied psychology. If you understand humans well enough then you can create good solutions for them. It’s not surprising — you won’t create a good cat toy if you don’t understand cats.
1. Keep learning how humans use software. This is rooted in our physiology, psychology, and culture. It’s remarkably sticky across different contexts, and it’s learnable. Watch people using software; get them to talk about what they’re doing. You can do this in a lightweight way with coworkers — “Will you show me how you do X?” Then pay close attention and ask questions.
2. Prioritize task context and workflow. For the most part, UI design is not nearly as important as workflow. How does a user get from where they are to a solution? Whatever solution you design must meet the user where they are, where they have the problem. So be very sensitive to user context — as you watch people use software, pay attention to where they start, and what expectations they bring with them.
3. Document and maintain concrete goals for all design work. Before you design, write down a small list of goals in the user’s own language. “User stories,” we often call these. As you work, keep going back to that list to make sure that you’re staying focused on what users really need, rather than what you think is cool. As you use new software, try to reverse engineer this list of goals — “What were the designers thinking? What did they expect me to do here?”
4. Check your ego, and learn to love being wrong. Put unfinished work in front of people. Cheerfully accept all feedback without explaining or defending. Always expect that your design solutions are not good enough, and can only be improved by testing them with real humans. You are not your user; you must position yourself to be surprised by them, and to react well to that surprise.
> 4. Check your ego, and learn to love being wrong. Put unfinished work in front of people. Cheerfully accept all feedback without explaining or defending. Always expect that your design solutions are not good enough, and can only be improved by testing them with real humans. You are not your user; you must position yourself to be surprised by them, and to react well to that surprise.
As someone with 15 years of UX experience, this is the "tool" that I find most valuable when it comes to improving a design I am working on.
I often tell my clients "I am not an expert" as a way to communicate this. I could never know as much about the problem users face as the users themselves, and I can never know as much as the entire team of people working on the solution. Instead I tell them I'm an expert at being a sponge, and learning from multiple inputs.
If your ego is telling you that you need to have all the answers, you're going to miss all the deep insights and therefor better outcome you would gotten within an open mind.
1 & 4 go together very well.
The biggest mistake I have witnessed, is a person putting work into a design until they thought it was "perfect/finished/happy with it" & were ready to show off.
They're going in expecting people to tell them how good their UX is, even if they won't admit it. As soon as someone struggles with it, you can see the original designer getting defensive or suggesting to the person testing to try it the way the designer intended.
I think a tool like Microsoft Excel is a great thought process for UX. I'm not saying it's perfect. But you have a product with such a wide audience experience range. You want it to be simple enough to get started with no experience & think of yourself as proficient enough to throw on your resume. Yet you also want advanced users to be able to improve their productivity with slightly hidden UX.
> I think a tool like Microsoft Excel is a great thought process for UX. I'm not saying it's perfect. But you have a product with such a wide audience experience range
Today MS UX, UI whatever they call it, is a destitute, a failed embryo. Using it every day is an exercise in masochism. Try to resize a window element with 1px width on a UHD monitor.
And i repeat myself: light gray on black ?
Really want to learn something from MS: see win32 until win 2000 and office untill office 97.
And waiting 1s for every cell in excell to advance is a ... problem, not a UX advance.
This is great. Everything I could think of and more.
All of my years dealing with UX, the best work I've done has been when I think less of what I believe, what I want, what I think is right; it's not about that. It's entirely about the people you're building for. They aren't users, they aren't UUIDs in a database, they're human beings.
I started my career fairly sure that I knew what I was doing and I knew how to solve problems. I was totally incorrect. People solve the problem for you, but you have to watch and listen. You can fill in gaps and use intuition here and there, but for the most part, you're working in the interest of the people you build for. They aren't using what you build in the interest of proving your sensibilities.
> People solve the problem for you, but you have to watch and listen.
I love this. It reminds me of my favorite saying about design: “People don’t design ships. The ocean designs ships.”
At work I try always to say “human” rather than “user,” for just the reasons you state. Like you, I think I’ve done my best work when I’ve been able to remove myself from the equation. It’s one reason I like building software that I’ll never use myself — it keeps reminding me that I’m not my customer.
You could write a dedicated blog post (or something) with your insights. (It would be easier for me to bookmark, from a pure selfish perspective). I would love a ping if you do so.
> 4. Check your ego, and learn to love being wrong. Put unfinished work in front of people. Cheerfully accept all feedback without explaining or defending.
Love this so much. As dev we often positioning ourself as user, cut it off by wireframe simulation. The things is, we are not the real user. We are not the person who will use the product. And we conclude the ideal design by fantasize it.
These are excellent advises. As a UI/UX developer I have way to often had to fight against a project manager who want a fancy—but ultimately useless—feature (point 2). I have also wrongly fought against a graphic designer because I failed to admit my own shortcomings, wasting everyone's time in the process (point 4).
I would like to add one point though. That it is important to use your own product. The worst UI is a buggy and slow UI. The set of potential bugs is way larger then what you can test for. If you use your own product you are way more likely to spot them, as well as experience first hand where slow response (or slow workflow for that matter [point 2]) is causing users pain.
Another one you should know is sometimes your users are wrong. You should still listen to them, but don’t implement blindly what they are asking for. If a user asks for a feature, ask your self: “Why do they want this feature, what is the problem this feature will solve? And can this problem be solved differently?”
Fucking feels like that sometimes, eh? :D You’re right, though! The high end of this is something we rarely approach in software — an observer with a clipboard, sitting in a duck blind in someone’s living room for a week, watching them watch TV.
If you do this right you know your users better than they know themselves. I used to think that was a bullshit turn of phrase, but now I believe it completely. I frequently notice things about people and their work that they’ve never noticed before. There’s a real skill to “close observation from a distance.”
At Microsoft, I can recall several UX/UI user studies that were conducted by two anthropologists. Although I don't recall exactly the studies, I know they had to do with future UI/UX concepts.
This. Well, minus point 3 or include the user feedback in your goals. Also keep in mind that most people cannot articulate what they really want but most of the time they will complain about a bad solution.
Also try to mimic the other applications your clients are using regularly - even when the UX is bad. It’s easier for them to remember one broken workflow than multiple.
I disagree in general with your second point. Yeah, sure, this could make sense in some situations, but many tools and products exist for the sole reason that they offer a superior workflow and smoother experience than their existing counterparts.
Wasn't there that classic HN post about users not needing Dropbox because any Linux user could do the same with rsync?
Yes, most people are idiots. Ever thought that for those people to "articulate what they really want" means for you to try to undestand them and to speak their (technical) language ?
So, a user story takes for form of, “As a User, I want to achieve Goal, to serve Purpose.” E.g., “As an SRE in charge of Kafka for the customer account service, I want not to be surprised by topic starvation, so that I can get home and have dinner with my family on time.”
In practice, sometimes I abbreviate these to just the Goal:
* I want not to be surprised by topic starvation.
* I want to be able to look at the report and right away know if there’s anything I should fix.
* I want to be able to see what configuration changes have been made recently.
Or, let’s take this for a simple product feature:
* I want my alarm to go off at 7:15 every morning.
* I want my alarm to wake me in time for early meetings.
* I want never to be woken early by mistake.
You can see that those goals may conflict. What if their first morning meeting is at 7am? Then we’ll need to override goal #1. What if they’ve been invited to a meeting but not accepted it? That surfaces a conflict between goal #2 and goal #3.
So a user may give you those three goals, and then as you design you’ll see the conflicts. That enables you to have a principled discussion with the user — which goal is most important? How do you want to handle goal conflicts?
The anti-pattern here is to design one UI that solves all problems with equal difficulty. A better solution is to prioritize those problems, and solve the common ones easily and the rare ones perhaps with extra work, but not at the expense of clarity.
Start with this list of goals to keep the work honest and focused. Update the goals as you learn more from users to keep the product responsive to their needs. Make sure, before each release, that the product/feature actually does meet these goals. Use the goals as focus points for user testing.
A little aside. In early 2000, the problem was how to introduce and educate businesses about UCD and UX design processes.
Nowadays, in my personal view, we have to balance all the UX/UI trends/principles/research with business goals more.
Starting with well-defined set of product requirements and KPIs and "keeping it in focus" is essential.
“The Design of Everyday Things” by Don Norman is excellent; he originally called it “The Psychology of Everyday Things,” but it kept getting misshelved. “Don’t Make Me Think” by Steve Krug is also very good. Neither of these is a specialist’s tome.
“Mental Models” by Indi Young is good, one level deeper, mostly about humans. “About Face” by Alan Cooper is very thorough on the practitioner side, more of a college textbook, with lots of examples and pedagogy.
Also look at Nielsen Norman Group (https://www.nngroup.com). The 'Norman' is the Don Norman who wrote the book, and NNG have a bunch of research that you can look at.
1. Keep learning how humans use software. This is rooted in our physiology, psychology, and culture. It’s remarkably sticky across different contexts, and it’s learnable. Watch people using software; get them to talk about what they’re doing. You can do this in a lightweight way with coworkers — “Will you show me how you do X?” Then pay close attention and ask questions.
2. Prioritize task context and workflow. For the most part, UI design is not nearly as important as workflow. How does a user get from where they are to a solution? Whatever solution you design must meet the user where they are, where they have the problem. So be very sensitive to user context — as you watch people use software, pay attention to where they start, and what expectations they bring with them.
3. Document and maintain concrete goals for all design work. Before you design, write down a small list of goals in the user’s own language. “User stories,” we often call these. As you work, keep going back to that list to make sure that you’re staying focused on what users really need, rather than what you think is cool. As you use new software, try to reverse engineer this list of goals — “What were the designers thinking? What did they expect me to do here?”
4. Check your ego, and learn to love being wrong. Put unfinished work in front of people. Cheerfully accept all feedback without explaining or defending. Always expect that your design solutions are not good enough, and can only be improved by testing them with real humans. You are not your user; you must position yourself to be surprised by them, and to react well to that surprise.