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.
It was the days of MS-DOS. I had written a program to manage the inspection of Fire Extinguishers in Fossil Fuel generating stations. The Operations manager pulled a random person in, explained to them that he understood they weren't trained for this, and anything that was wrong was MY fault, not theirs. He gave them a list of things to do, and told me to watch and not say anything.
The user got stumped at 1 second into the task... and I blurted out "just press F1 for help"... to which the reply was "How is he supposed to know that?"... and thus began my education of building appropriate user interfaces. F1 was ALWAYS on the screen after that, and I learned lots of things about the differences between someone just trying to get a job done, and my view of computers.
Some light theory and heavy practice is the best way to improve. Credentials: been doing UX work for 25 years and I run https://www.TrialToPaid.com where I'm well paid to improve UX to grow trial conversion revenue.
Here are three steps you can take:
1. Read Don't Make Me Think by Steve Krug, User Interface Design for Programmers by Joel Spolsky, Refactoring UI, and (optionally) The Design of Everyday Things (this will get you paying attention to UX and UI in the real world). The core principal of good UX is Spolsky's maxim: "A user interface is well-designed when the program behaves exactly how the user thought it would."
2. After reading, go do 10 hallway usability tests on an interface you know well.
3. Then redesign the interface using the principles from #1 and run usability tests on that. Later, rinse, repeat.
The main idea here is:
1. Get some decent grounding
2. Learn from where users stumble over an interface
3. Try and improve the interface
4. Get feedback on your improvements (did they help? what other problems did they cause?)
I consider usability to be a critical component of "UX."
I started by reading The Design of Everyday Things. It's a book that changed my life. There was just a thread, hereabouts, about the book[0].
I also took a few classes with the company that Don Norman co-owns (NNG)[1]. These are useful, but not a "philosopher's stone." They tend to push user group testing a lot, and I'm not a huge fan of UG testing.
I tend to lean on the platform standards, a lot. As I develop Apple software, that's easy. Apple has a very heavy-duty tradition of UI[2]. It's not perfect, but I keep on tossing out my fancy custom UI, in favor of the built-in UI.
They did a hell of a lot of work, so I don't have to. I usually regret "taking the road less traveled by."[3]
I strongly suggest getting familiar with the built-in UI for whichever platform/industry you are working with. Look at ISO icons[4].
I remember someone doing a write-up, once, that nailed it. I won't be able to come close.
First, regardless of how well the group is chosen, it will never truly represent the actual user base. As long as that is kept in mind, while reviewing the results, that's great; but, in my experience, people tend to believe that the UG actually represents a valid proxy of the destination users, and aren't prepared, when the actual users get their hands on your baby, and start clicking on the wrong buttons, and not understanding something that's "perfectly obvious," etc.
Next, the group knows they are testing, and will do things like report an issue, instead of working around it.
That may seem to be the best thing, but the workarounds can tell you a great deal. Usually, it's discovering that the users have an entirely different mental model of the UX than you had thought. I've found that it can sometimes pay great dividends to "lean into" the "incorrect" mental model. It can make a night and day difference on how the product is received.
They may also not use it in their everyday work. At the company I used to work for, the UG was done on-premises, in a special room, with one-way mirrors, and cameras, all around. Users were given specific workflows, and did not use the software the way they wanted to.
We paid a lot of money for that, and it didn't tell us squat. It just gave us some "low-hanging fruit" feedback.
Also, it was my experience that managers and architect-types did not want to hear information that went counter to their own context. They would write off the results of user tests that indicated that their "baby" wasn't exactly a hit. This was about personal bias and ego, but, when the person writing the checks doesn't want to hear bad news, guess what? No bad news reaches them. If the product tanks in public, it gets a lot harder to ignore the bad news.
A well-done UGT can get things like this, but, in my experience, that doesn't happen.
Also, UGT is usually done under a veil of NDA/secrecy. Once the product hits the streets, people start hacking it, and, in my experience, these hacks can put my original work to shame. In one product I created, I worked for months to create some truly awesome clients for my backend. These were masterful. They answered all needs. They made the product great.
And no one used them. I used to receive almost constant bitching about my work.
Instead, a relatively "bad" programmer created a WP plugin, that everyone wanted to use.
Eventually, I threw in the towel on my client, and the new team that took over, made his plugin the reference implementation (including things like adding JSONP stuff that allowed it to be broken away from WP).
I am not a fan of sloppy MVPs, but there's a lot to be said for putting working code in front of actual users, in their "native" context, and then carefully observing them, in a non-Heisenberg way.
So, I guess TL;DR, is that I think controlled UGT is nice, but expensive, and of limited value. Open betas are probably better, as long as there is some way to solicit feedback on how the product is used.
Dealing with negative feedback sucks, but, in my experience, that is what is required to improve the product. I've received more value in profanity-laced diatribes, than in reams of Excel spreadsheets.
Honestly, I'd work in customer service. I learned so so so much from interacting with real people.
Waaaay-back, I got my start ay The New York Times as a customer service rep (2003?) for the website. I walked people through password resets, duplicate crossword subscriptions, cancellations, and even helping them search for articles. Lots of random interactions.
It opened my eyes to the ways that UX helps and hinders people, and sends too easily them in the wrong direction.
That to me was the best and biggest starting point in UX design; the first-hand perspectives of others, and empathy.
Disclosure: not a professional designer/UX person but have learned a lot over the years.
Honestly, building things that were terrible (not on purpose) and going back later and trying to pick apart what I did wrong. User feedback is really important here. Things like "how do I do..." or "where is the button to..." are signals that your UX needs improvement. I think it's useful to be able to look at your work with a critical eye. Of course, if you have the ability, show the things you build to a designer and ask them for honest critique.
Put yourself into the shoes of a user and work backwards from there. When I first started doing UI/UX, I put myself in the shoes of a programmer and worked towards the design. This will not ever work. Come at it from the perspective of "if I were to use this app, what are the most useful features and how do I access them?" Work backwards from there and have your UI/UX inform your architecture. Not the other way around.
Also, one thing that has helped me is to not get too wrapped up in design trends. It's a distraction from developing a solid foundation. You can have a great UX that people like without having to do the LATEST thing.
One last thing: it can be good UX without being beautiful. To me, UX is about discovery: can people figure out how to use it without consulting the manual? If so, it's good UX. The design might be trashy and look 90s but that's less important than having something people are comfortable using.
For me, Windows 7 is the peak in terms of UI/UX. It has been refined over many years, and it was close to perfect, so much that between later versions, nothing changed much. In Windows 7, changes were mostly cosmetic, taking advantage of modern graphics hardware and it was good. So it is certainly a good guide.
Windows 8 broke everything and we still havent recovered. I blame mobile devices, as designers now try to offer a similar experience on mobile and desktop devices, which is a good thing, except it is almost impossible to do well.
I don't know much about the Apple ecosystem, I am sure it is great, but did they survive the mobile apocalypse and managed not to mess things up?
> I don't know much about the Apple ecosystem, I am sure it is great, but did they survive the mobile apocalypse and managed not to mess things up?
They didn’t. Flat design, invisible scrollbars, lower contrast, rounded corners, unintelligible monochrome vector icons, and other loss of affordances have found their way into macOS (and iOS of course). But at least the macOS UI does not try to be touch-compatible.
I usually recommend the following to people I work with:
Practice, but also in all aspects of life, UX - User experience, is not limited to only the realm of computer interface.
Learn to paper prototype, by hand, no computer, no rulers, it's not meant to look pretty, at lest not at first (graphing paper is recommended).
Read Norman's design principles (https://www.educative.io/answers/what-are-normans-design-pri...). Why because they are short and concise, and a good starting point, but not necessarily the be all and end all. (First learn the rules, understand the rules and why they exist, then if needed break them.)
Then look at everything in to world, everything at one point had to be designed. Ask yourself what was the reason. Why did something get build they way it did. Read up on general design and look into intent of why something was/is done a certain way.
Why are milk and eggs at the back of a store? Why are they together?
Look at every door handle, why is it the way it is, what does it communicate?
Sidewalks, roads, crossing, traffic lights, color usage, shapes, position orientation. Look at everything around you and work out why it is the way it is.
Once you catch yourself doing this subconsciously, look at graphic design, ads, magazines, chose your own adventure books. (Slightly off topic but a good radio series: https://www.cbc.ca/radio/undertheinfluence)
In the end keep in mind, that a lot of design is a response to a need, Sometime bad design is needed, bad design forms a presentence, and unless you are willing to retrain every user, you likely have to follow it... think Qwerty keyboards.
Also keep in mind what each step is doing. Is it clear what to do? What will happen next? Why am I filling out this form (again)? Above all use your GUI. Use it yourself. Pretend you know nothing of the space and is it clear what is going on? Grab someone and have them use it, do not walk them through it. Can they get through it without help? Are they getting stuck? One that has been bugging me for a few years now. If you have something that is required. Make sure it is marked. Make sure if they hit next you do not clear out the whole form.
Give your program to a real user. Ask them to do a task. Shut up, look, and watch 'm squirm. Keep up for an hour. If you start assuming this particular user must be braindead and failed basic logic, repeat with a new real user until the lesson sinks in. Realize your crystal-clear design has in fact plenty of holes, and user will curse your name if you release now. Bang head against wall for therapeutic value (your head, not theirs). Congrats, you're now an UX expert.
I did it once. Turned out my understanding of the real core problem was deeply flawed.
UPDATE: Maybe interesting to give some details of this. I was developing a program everybody called the calendar. Basically there's a list of people, and they need to have a timeslot each somewhere in the next year. Customer was the people who scheduled these time slots.
First version of the calendar app was ... a calendar. Columns monday tuesday wednesday ..., rows with hours and minutes. Drag a person on top of it and presto. You know the drill.
Testing with users revealed something was off. No user could really tell what was wrong, it looked exactly as they had asked, but everybody agreed this was not it.
Somehow, the better design dawned: Even if they called it a calender, they wanted a task list. Not the date/time aspect but the person aspect was central and required most screen estate. They needed to be able to select the right people in the right order, giving priority to some people but also being sure nobody was forgotten. Date/time selection could generally be automated or needed a simple text field so they could quickly type it in.
The redesign took about a day. All the business logic and most of the UI widgets could be recycled. Just had to add a dumb list with checkboxes. Nevertheless, it looked completely different when finished, with widgets moved between pages and resized as their importance grew or shrunk. I kept a calendar widget in there out of some kind of residual guilt, but it was almost completely ignored.
Maybe another fun example: Data entry. The state has some official paper form, people want to type it in the computer. So I created a page with fields in a reasonable order: First identification, then contact info, then the different aspects forming the purpose of the form.
One day, I manage to acquire an actual form as provided by the state. It turns out to be organically grown and the resulting field order made no sense at all. The first field was a phone number, for some reason. Name and surname were actually on 2 different pages, with lots of stuff in between. No idea how it got so messed up.
So I ordered the fields in my form in the same bad order as the state form. Users loved it. The could just tab-tab-tab quickly fill it in.
> Realize your crystal-clear design has in fact plenty of holes, and user will curse your name if you release now
If you're a designer working with some web folks... don't be too proud to take their feedback as well. I've lost count of how many times I was given a set of mockups that were confusing. When I raised the point of "this is confusing to me - I don't understand X"... sometimes it's taken to heart and we converse and iterate. Sometimes it's not, and I'm pushed to "just do it like this", which almost always leads to ... a big delay in getting the exact same "this is confusing" feedback from people weeks or months later.
To be fair, this hasn't happened to me as much in the last... 3-5 years. And there are times I really do not know the domain very well. What's confusing to me is 'industry standard' (labels/names/workflow/etc) - sometimes there's even regulatory reasons for doing things a certain way. I learn from that.
The other side of that is... I've worked on systems for 6-12-18+ months, and know how the system is currently providing value. "Designer X" coming in and making radical changes without any ability to give them feedback - at any stage of the game - is just really bad.
If someone has more experience in X, and tells you "this is confusing/wrong", they might just be correct, and everyone can save a lot of time by addressing the confusion earlier rather than later.
> Even if they called it a calender, they wanted a task list.
I've hit this exact one a few times, from both angles. Wanting a task list, but calling it 'calendar', and wanting a calendar view, but using "schedule". Takes some digging and sometimes side by side comparisons of 2 or 3 different visualizations, but eventually we get there :)
I try to think UI-first. When I start a project it's not "How do I implement this functionality" it's "How do I make this UI".
UX is a lot deeper than where the buttons go, it's about workflow, and architectural decisions can constrain UI. Using a UNIXy suite type model? You might have trouble editing an earlier decision without undoing all work after that, unless you are very careful.
Some architectures might make auto discovery and drop boxes hard and users will need to type IP addresses themselves. I'm convinced a top notch UI has to be a goal from the start, or it will take twice the work.
Good UX means the actual functionality is designed based on the psychology of the users, not the logic of the task. An undo button is worth more than beautiful code. 2 redundant buttons that do almost the same thing, that could just as well be done by manually entering parameters, is fine if that's what users want and it will save time and stop mistakes.
You're not modeling a task, you're modeling how a user does a task.
Next up, white space. It really is important. Packing 200k things on screen will annoy everyone. Modern UI design might disappoint some in terms of aesthetics, many people hate the ultraminimal look, but the layout is pretty good and paying attention to how everyone else does it makes sense.
When was the last time you needed a manual or google to use an Android app? Almost never for me, because they are self documenting and things just work.
Packing 200k things on screen will annoy everyone... except power users (not literally 200k things obviously).
If you're building a specialist, usually business, application then often all the users will be power users fairly quickly, because they will spend all day every day in your application. In this case their priority will be doing things quickly and accurately, and having all the information they need available when they need it. My priority as a UX designer in this instance (or my priority as a designer herder these days) should be enabling them to do this, and not making stuff look pretty and well spaced in the first instance. This will often involve cramming lots of information and icons into a small space and minimising white space, and will sometimes involve making an application hard to use for newcomers. And that's fine! If it is a bit of software that someone is going to be using 40 hours a week for the next 10 years then the priority is the user who already knows the system, and not the user who is learning the system. Although you need to ensure that the system is actually learnable, which is largely about consistency, documentation (gasp!) and tutorials, and surfacing the most frequently performed actions.
I just went through a battle with a UI designer who wanted to break up an existing interface used in a marking tool into several screens because the current UI was hugely cluttered (which it is) and intimidating (yep, looks scary) and hard to learn (actually not, onboarding of a new user takes about 30 minutes. 25 of which is them following a long to a video). The design they came up with would have looked much nicer, but would have resulted in a much poorer UX, as it would have involved the assessor switching between multiple tabs, scrolling up and down and dragging and dropping items across the screen. And doing this literally thousands of times over the course of a couple of weeks. I'd already been through a similar battle with a previous UI designer to eliminate drag and drop in the same interface a couple of years ago because I had a user develop RSI using it. In doing so I made the I terrace uglier and more cluttered but eliminated many hundreds of drag and drop actions a day for each user.
Anyway, moral of the story, sometimes a good UX is only possible if you have a "bad" or at least ugly and cluttered UI. This doesn't mean that you should ignore aesthetics, or go out of your way to make things ugly, but that sometimes cluttered, information dense and unintuitive to new users is the way to go.
> Next up, white space. It really is important. Packing 200k things on screen will annoy everyone.
My favorite rebuttal is Excel. Imagine Excel with no more than 10 well spaced buttons in the tool bar and a quarter inch padding around every cell. Totally unusable for most of the things we do with it.
I think of the problem first. We often go straight to the solution without a clear understanding of the problem.
Sometimes, the problem does not require a UI at all. The solution is somewhere else. As I was building a UI for someone to perform a task, I realised that the task could be entirely automated. I was tackling a problem on the wrong layer.
I think that you should start by modeling the task, because the user might not need to do that task in the first place. "How a user does a task" is how we get faster horses instead of automobiles.
> When was the last time you needed a manual
I suspect that it has a lot to do with growing up using those devices. Give one of those devices to your grandma and watch them go.
It partly depends on where your skills are at, currently. "Refactoring UI" (the book and their videos) turned out to be a great resource for me when I read it. "Don't Make Me Think" as well.
This is not great advice, but I try to make sure I only write software that I use. That way if something is painful to me, I know people that didn't write the code have no chance of being able to use it, so it has to change.
Certainly, in a software engineer's career, you'll often be asked to make things that are not directly useful to you. Force yourself to use them anyway, or you miss that valuable path of getting feedback -- "do I even like it?" If you made it and you don't like it, it's probably not good.
I think this, in general, does yield pretty good results. I think software engineers have much better work tools than other engineers (Emacs is a lot nicer than Solidworks), and that's because you use the tools you make to develop the tools you're making, and get a lot of experience in what it's like to be a user.
Exposure. Try a lot of software, like everything you can possibly get your hands on to play with. Start with your area of interest, or focus of work, but don't limit yourself to your space. Try as many applications from as broad of fields as you can. Try to find something you like about everything you try. Try to articulate exactly what you like about it. Try to find something you hate about it. How would you improve that thing you hate? Practice thinking critically.
You'll start to collect ideas and make connections of interesting interaction patterns. Maybe the way they handle a mini-map in a random GIS software you tried would be perfect for an unrelated music composing app you are trying to build. Maybe you see a great settings config in an a 3d texturing program, or a video game, but it has exactly the range of features you need.
Mu number 1 tip from some 20 years of watching UI design evolve:
Design that is more accessible for users with disabilities is more accessible for everyone.
The first level of this is easy, but few do it.
Step 1: use a desktop PC. Windows or Linux as you prefer, but not a Mac, and not a laptop.
Step 2: unplug the mouse. Learn to do everything with the keyboard. The WWW is a pain but most other things are easy, but you'll need to learn the keystrokes. Few know them these days. Windows is good at this, and you'll quickly discover that most Linux desktops are poor. (For me, Xfce is about the best.)
Spend a week working like this. You will discover a tonne of stuff about UI design you never noticed before.
Step 3: for the most advanced users only. Now you are used to working without a pointing device, install a screenreader -- NVDA for Windows is good and free. Now, unplug your screen. Learn to work with keyboard and sound only.
I am part way through learning this and it's savage, but it's like learning to play chess blindfold. Once you have the patterns in your head, you discover that you don't need to see them and you can still be fast and efficient.
But steps 1 & 2 will put you in the 1% of best UI designers there are in the world today.
I think the best way to increase your user experience skills is to be comfortable using design patterns. By learning how to use them, you will be able to create a consistent experience for your users, which can make a big difference in their overall satisfaction.
Another thing that helped me was studying designers who inspire me. Just looking at their work and seeing what they've done gave me ideas for new features and ways of improving my own designs.
I also invested in my education by taking classes and seminars about UX design. By doing this, I learned more about industry best practices and how other people were solving problems similar to those I encountered at work.
Deciding on your concentration was an important part of my education because it helped me focus on what kind of designer I wanted to become—web UI designer or UX researcher? Once I knew what type of designer I wanted to be, it helped me set goals for myself that would help me achieve my dream career goal (e.g., get hired by Google).
Implementing your learning is very important as well because if you don't practice daily then nothing will change! So, after reading articles about UX design patterns and techniques on
There’s many things you can do outside of work that others have suggested.
In terms of making your UX skills better, try doing some UX work and ensure you have a complete story.
Share a crisp problem you’re solving that’s focused in scope. Share an audit of similar experiences that inspired you (they shouldn’t just be competitors). Share insights that you gained from that audit.
Then after all of this, share your mock-ups and reinforce them with how and why you landed there.
Overtime, you will start to get really good at thinking of parallel experiences that will inspire your work.
As a designer, I’ve found all teams to be really receptive to this process (especially eng that can review those audited experiences and agree or disagree with your points).
Edit: this should be obvious, but talk to your users as often as you can and always ask why to get to the heart of their points
I believe most concepts, like UX, can be broken down into multiple pieces, each of which can be described on a spectrum.
On the right side, we may find:
* consistency
* metaphorical
* discoverability
* ease of access
* attention to detail
On the left side, we'd find the opposite.
Where to be on the spectrum depends on context. For example, a sales page need not be as concerned with consistency as an application.
Being conscious of the existence of these concepts is key. Example: what does '...' mean in many applications? If you don't know, did you subconsciously?
And don't forget, design is partially subjective, however, a decision may be objectively inconsistent, un-metaphorical, etc.
This one amuses me. You skip the long-windedness of the front page to look at the pictures. Your eyes are caught by two example user interfaces: contact forms. The one on the left looks great. The one on the right looks awful. Yet it's the one on the left that has the big red X next to it. So you backtrack to read why they're wrong. The reason is because borders "feel" busy and cluttered. Nothing empirical. No data to back it up. Just "feelings".
This led me to believe the whole website/book is going to be like this, so I haven't read any further. I'm sure it's great.
> The one on the left looks great. The one on the right looks awful.
This is also just a mere assertion of "feelings", with nothing empirical and no data to back it up.
As long as those are the rules we're playing by, I'll say that to me, the design on the left screams "designed by a dev", in the pejorative sense, while the one on the right looks like it had a designer involved.
Whether there are actual usability improvements is an orthogonal issue, but I don't feel there's a huge gap between the two.
I feel a lot of this comes down to trends, rather than actual usability. Keeping up with the latest trends in UI design is a signal that you care enough about design and UX to employ and empower a designer/ design team.
Paradoxically, sometimes signalling you care about design might involve making the UX worse (relative to what the user base is trained on), if that's what the trends dictate. For example, the sudden overcompensated reaction against skeumorphism that was "flat design".
I started caring about users. I decided that I genuinely want them to enjoy using what I build - not in a "hey that's cool" or "ooo that's beautiful" way, but in a "wow, doing that sucky task I have to do every day is a bit less sucky now" way. I put effort in to solving hard problems so I can make users lives a bit easier. It turns out that thinking this way also makes my job more fun.
This is what I was going to say, but even simpler...give a shit how the UI/UX works and looks. That means thinking about the details and how something is really used.
You look at it again, you again scream inside your head: So, what is the user actually trying to do? Then you hate on your previous solution until you are convinced it is terrible. The only thing it has going for it self is that people are now used to your terrible thing. If you are going to change it it better be dramatically better. You have 100 ideas that should all be considered bad. You prototype a few of them and try to convince yourself you've made it worse. If this fails you try to convince yourself the improvement is not big enough. If this fails you make more prototypes. If you are going to screw with peoples muscle memory you want larger gains out of the mistake.
Then you put it live, if enough people hate it you revert it back to the original version. If more people complaint how the new version was actually better you go back to the drawing board.
If no one cares however, then you've done a good job.
Listen to feedback but don't involve the users outside live testing, they don't have the hate one can project on ones own work. If they could give useful feedback it is something obvious that you convince yourself you should have seen.
edit: Dogfooding is good but mind the learning curve. Dogfooding might actually be required to approach perfection.
I'm not a UX developer by trade, but I've had to develop UX in my time so I've picked up some things.
It's not about how fast you get to something.
You talk to users and they will go on and on and on about "clicks". Anyone talking to you about the number of clicks doesn't understand UI let alone UX. Making everything "one click" away is how you get those massive button interfaces. It's just information overload and even harder to navigate than something that would take more clicks to navigate.
Another way to think about this is that a book takes many "clicks" to write. And a book that was written in one "click" wouldn't be good to read. Some long books are quick to read and some short books take forever to read. Flow is way more important than number of actions.
Realizing that always shooting for "easier" is a mistake.
Things must flow. Except where they shouldn't. Sometimes you want to actually put in resistance. Sometimes you want to make sure that what a user does is actually what they want to do. You want them acting with purpose and intention. If something has a large effect on the system, you want people to not accidentally do that. The best way to do that is to make it slightly involved.
For business apps, make an effort to become a domain expert and user/operator on their subject and focus on making UIs easy to use, as opposed to easy learn and difficult to use.
“…if we were focused on making everything easy to learn, rather than easy to use, we would all be riding tricycles. The bicycle is harder to learn to ride, but much more powerful.”
Zafka seems to be recommending "The Design of Everyday Things" here, from that link which appears mangled to me.
(looks like there are many books with similar names!)
Trying ideas out with an expert in the field. Listening to their criticism. When they, or someone else, is confused by the operation of my work, understand that it could be a UI fail and make efforts to make clearer the communication between application and user. Above all else -- practice.
Being a good UI designer is like being a good writer -- your job is to communicate all that your audience needs to know, without overwhelming, confusing, or distracting them. A balance needs to be struck. What, in any given moment, does the user need to know? How do you arrange that information so that it's clear? How do you present the different choices to proceed to the user? It really boils down to, if the user knows at a glance what the situation is and what they can do next, you'll be fine.
You don’t need to build a product in order to user test. You can take an existing product, watch a totally new user use it for the first time, and learn a huge amount.
I suggest doing this for a type of software that you know really well, as you’ll be more surprised by your own assumptions.
I am sponsored by my company to complete a UX certificate for my continued learning goal. The beautiful thing about it is since my company is aware of my learning, not only that they support me financially but also positively look for opportunities that I can apply what I learn to real-life projects. That helps me learn and improve my UX mindset significantly over the time. So I would say taking UX courses, reading related articles, books, resources are important but the key tip is searching for projects (personal or professional) to apply what you learn as soon as possible. It should never be too soon or “I don’t think I am ready yet”. You got it.
UX is very much rooted in both industrial design and psychology. I would highly recommend taking design courses in college, it will help hone your eye for how to perceive a task through a given experience.
Contrary to popular belief, UX has nothing to do with software: UX is just the sexy new term. It all stems from design, and was studied heavily in the early 20th century onwards. Look at a can-opener, for example, or the classic Jerry-can from WW2. It is about how humans interact with the world through design.
There are many ways to improve your UX skills. I've gotten to know UX here for 6 years. I'd start to research all the things about UX, try to learn from the foundation to advance knowledge, I found all the things related to UX on the internet, join the designer community (Facebook, Reddit...) to learn from each other and senior guys. Besides that, UI UX design tool can be very helpful to practice your skills, such as Figma (for pro player), Balsamiq, Miro, Visily (for newbie).
Some people recommend taking a course or reading books on UX design, but I believe the best way to improve your skills is to get out there and practice. Try designing simple apps or websites, and get feedback from friends or family. Use online resources to learn more about specific UX concepts, and then apply what you've learned to your own designs. With enough practice, you'll start to develop a good sense of what makes a good user experience.
The best thing I ever did was just sit and watch people use my software. You can get very deep into theory and psychology, and that stuff is fun and useful, but at the end of the day I got learned more ROI on my time from watching people use my software than anything else I did. Ideally, you're just a fly on the wall, but even if you aren't it's still a useful data source.
I think that using systems with bad UX teaches you a lot on what not to do.
I was unlucky/lucky to use Lotus Notes for about 4 years, and that changed my perception on how much suffering software can inflict on its users. If you have a friend/relative that happens to work with it, try interviewing them.
Lol. Good ol' Lotus Notes. I think it's safe to say that Lotus Notes has no UX other than the UX that emerges from its ad hoc nature as a piece of software. I wish I had kept my list of Lotus Notes shenanigans from the time when I worked at a company that used it. I don't think I have ever used a worse piece of software.
When I worked for a company selling aircraft spares, I was talking to my users every day. Everyone: from MD, though the call center, all the way to the warehouse.
Seeing how they want to work and listening to what issues they had helped me "get into their shoes", thus make the software work the way they wanted it to work.
The Science of Great UI is an amazeballs course. Like knock you on your ass amazing. I could not recommend it enough. Mark Miller is a genius. http://www.sgui.com/
I learned CSS working email before and after the release of IE7. IE7 had a completely different box model than IE6 and email is incredibly primitive and unforgiving. Webmail is even worse.
I learned JavaScript when I was involuntarily reassigned from a design job to a developer job. I just had to figure it out. I learned to write code in an imperative functional way because I didn’t have prior bad practices and I didn’t want a bunch of vanity decoration.
Lately I have been maintaining an OS GUI in the browser. It turned out to be easier and faster without a framework. Less is more when there are many moving parts and competing concerns. What helped me the most with this is good test automation against user events in the browser. I was able to write my own tool to do this and so long as the page was served from localhost I didn’t have to mess with the complexities of CDP.
I am not a UX guy but I feel a lot of them could benefit from trying to understand their users and what the tool is actually used for. I feel a lot of them have a “I know better” attitude and don’t respect their users.
In case no one said it yet, take your ui and perform every sensible action path one hundred times. Most of the fancy animations, drawers, pickers and beauty-based designs get old long before you’re halfway there.
Tell yourself and others that you're and empath and that you're human-centered. Seek out like minds and converse with them about interfaces. Do it lots - for years.
6. Looked at other sites and tried recreating them
7. Eventually I learned how to use photoshop but I still didn't get what made things look good, I just knew X looked better than Y???
8. I started to learn graphic design.
9. I learned lot of design principles, art functions, colors, reptition, texture, ... yet it still didn't click.
10. Gave up but got interested in digital painting timelapse videos, where authors would go over why they are doing what they are doing.
11. I had epiphany!! Everything in design should have purpose. Every thing that's visible or not should have a purpose, a feeling, a message. Everything should be intentional. Participated in lots of competitions and overtime honed visual skills.
12. Ok now I could design beautiful stuff but what to put again, I can make it pretty but what should be the content. Introducing UX research.
13. Turns out you should do some research and gather some details on what you want on the page. Who are you building for, what do they want to see or do, what do you want to show/sell/convey.
Summary of few rules:
- Elements of design: Line, Shape, Color, Texture, Pattern, Negative Space, Mass, Contrast, Proportion, Proximity, Spacing, Balance, Photography, Positioning, Variety/Richness, Consistency, Movement, Rhythm, Tone Of message, Theme, Typography.. you manipulate these to do rest of things.
- Things together are seen as one, things same color are seen as together, and vice versa.
- Contrast makes things stand out, contrast can be achieved by altering color, size, spacing, arrows.
- Colors give feeling (excited, calm, stability), there are color pairs that go together well. Blue/orange, white/red... There can be pairs of 2,3,4 or 5 colors. Some colors don't go well together ie. blue/red. Cue human biology.
- Fonts are either serif or non-serif. No point in memorizing all fonts, just browse good font pairs. Usually different fonts for heading and paragraph makes the contrast easy to achieve. Again different fonts for different purposes like colors: think happy birthday font vs lawyer office logo.
- Best navigation patterns are which are common, not new ones.
- Anything that is inconsistent should be intentional or it leads to confusion. ie. differing space between buttons, random font sizes, different shades of colors, etc.
- Use inspirations liberally and then pick what you feel will work for your project, I use dribbble.
- Colors next to each other look different then alone or other colors. Brain automatically fills up few things. Think about optical illusions where one side of box looks brighter or a dress looks like its different color but both are the same color, but due to their proximity to other colors make brain interpret them different.
- keep in mind how colors work in nature, there is blue ambient color everywhere even in shadows, sun is at top and that affects how we see shadows and see things with shadows having depth.
There is somewhat standardized method to do research, I tried documenting all artifacts that a UX designer working in corporate would produce:
no, just some notes of mine. the main thing to learn is that everything that's on the page or not, and how it's there adds to meaning. Added a visual guide showing some examples of how to apply principles...
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.