Ask HN: How did you increase your UX skills?
Hi HN,
as a Software-Developer, I'm looking for resources that could help to raise my understanding of UX design.
So a simple question: What helped you increase your UX skills?
as a Software-Developer, I'm looking for resources that could help to raise my understanding of UX design.
So a simple question: What helped you increase your UX skills?
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.
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.
Wasn't there that classic HN post about users not needing Dropbox because any Linux user could do the same with rsync?
I was thinking of adding/integrating new processes. That’s imho the harder task because you usually have less data to work with.
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.
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.
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.”
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.
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.
“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.
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?”
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.
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.
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.
more here: https://sixzero.co/2021/06/02/how-to-design-confidently-with...
Could you maybe provide an Example for your third point? I think this will help the understanding how this could look like.
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.
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.
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?)
It's an instant redirect to another domain.
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].
Being "unique" is not always a good thing.
[0] https://news.ycombinator.com/item?id=32135115
[2] https://developer.apple.com/design/human-interface-guideline...
[3] https://littlegreenviper.com/miscellany/the-road-most-travel...
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.
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.
The rest can follow after that.
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.
https://stayux.substack.com/s/ux-design
UX is a deep topic. But from software-developer perspective you must cover the basics (if you choose so).
My book recommendation list: Laws of UX: Using Psychology to Design Better Products & Services
https://www.amazon.com/Laws-UX-Psychology-Products-Services/...
Think First: My No-Nonsense Approach to Creating Successful Products, Memorable User Experiences + Very Happy Customers
https://www.amazon.com/Think-First-No-Nonsense-Successful-Ex...
About Face: The Essentials of Interaction Design
https://www.amazon.com/About-Face-Essentials-Interaction-Des...
I hope this helps, good luck:)
https://docs.microsoft.com/en-us/windows/win32/uxguide/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?
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.
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.
Good luck!
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.
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.
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 :)
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.
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.
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.
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.
A couple of the recent older threads on this: https://news.ycombinator.com/item?id=29428533 and https://news.ycombinator.com/item?id=26932020
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.
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.
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.
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
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
My goal was 100 interviews. To get a hang of it. I finished my 300th interview recently.
For me, as a software developer, there is nothing harder and more valuable than those conversations.
On the right side, we may find:
* consistency
* metaphorical
* discoverability
* ease of access
* attention to detail
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.
In my exp, I tried a lot of software, then remember what make me happy when using.
Apply these designs in practice. Watch other people using, and improve. Then do the loop.
Then if you have time, read books later. Practice make more sense.
This is the critical bit. Build-what-you-like only gets you so far.
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.
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".
Just some of my feelings.
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.
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.
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.
He’s fantastic. The course was great. I came away with a lot of useful tools and a change in my mindset
- https://hundred.user-interface.io <- this is especially good
- https://twitter.com/vponamariov <- he often has great threads
“…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.”
- Douglas Engelbart
The Design of Everyday Things by Don Norman
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.
I suggest doing this for a type of software that you know really well, as you’ll be more surprised by your own assumptions.
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.
It's already been well worth the cost and effort.
To get your started, I recommend this short summary about universal design, inclusive design, and accessibility:
https://sayyeah.com/digital-insights/universal-design-access...
There is a simple secret to a great UX.
USE YOUR OWN PRODUCT.
Ignore designers, they have no idea what a UX is about. Pretty != Workflow. Workflow is king.
Find something you do all the time that takes 5 steps. Make it 1.
Find something that annoys you? Fix it.
Find something that's slow? Make it fast.
Find something that confuses you? Make it clearer.
That's all you need for a good UX.
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.
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.
An interface is a story. Even better, an interactive story.
P.S. I also found that it helps a lot if you read the copy aloud when designing it.
Tech companies with great engineers and designers have given away these for free. I try to stand on their shoulders.
Sort, simple and insightful.
- The book The Design of Everyday Things - The podcast 99% Invisible
1. I downloaded photoshop
2. Opened it
3. It was white page
4. I drew a red box
5. Stared at it (was it good? was it bad?)
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:
-Define Target Segment
-User segment matrix (access, value)
-Observe/Talk/Analyze Figure out how things are
-Find out possible paint points
-Experience Map / Journey map
-Empathy map
-SWOT analysis
-Competitive Analysis Features
-Stakeholder Mapping
-Analyze and Pick Pain Point
-WHAT WHO WHERE WHEN
-FIVE WHYS
-Crazy 8
-Affinity Diagramming
-Group Critique
-Scenario Mapping
-Solution Generation
-HMW
-Storyboarding ideas picked from crazy 8
-Solo critique
-Group critique
-Business Model canvas
-Value proposition canvas
-Pick Solution
-Feasibility vs Impact Chart
-User Persona
-Solution Creation
-Use Cases / User story (as a user..)
-Feature Brainstorming
-Must/Could/Should/Wont have
-User Journey
-User Flow
-Card sorting
-Wireframes
-Moodboards
-Brief (goals, criteria, spec, etc)
-MVP
-A/B
Build something that works.
Then make it likable.
After that, go for lovable.