Ask HN: How did you increase your UX skills?

[+] sonofhans|3 years ago|reply

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.

[+] nf__85|3 years ago|reply

> 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.

more here: https://sixzero.co/2021/06/02/how-to-design-confidently-with...

[+] mattferderer|3 years ago|reply

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.

[+] steve_adams_86|3 years ago|reply

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.

[+] entropie|3 years ago|reply

This is a great post.

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.

[+] solarized|3 years ago|reply

> 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.

[+] runarberg|3 years ago|reply

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?”

[+] mmcdermott|3 years ago|reply

There are days where I would (somewhat tongue in cheek) say that UX is more anthropology than psychology.

[+] sneusse|3 years ago|reply

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.

[+] staticBr|3 years ago|reply

Thanks mate! That is a nice and reflected way of approaching the subject.

Could you maybe provide an Example for your third point? I think this will help the understanding how this could look like.

[+] stayux|3 years ago|reply

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.

[+] adam_ellsworth|3 years ago|reply

Great context! Do you have any books you can recommend to become better at thinking/working in these ways?

[+] btbuildem|3 years ago|reply

Context and workflow, 1000x

[+] mikewarot|3 years ago|reply

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.

[+] kareemm|3 years ago|reply

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?)

[+] shockleyje|3 years ago|reply

Your site is down buddy

[+] asdjfhjlaksdhf|3 years ago|reply

links broke

[+] ChrisMarshallNY|3 years ago|reply

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].

Being "unique" is not always a good thing.

[0] https://news.ycombinator.com/item?id=32135115

[1] https://www.nngroup.com

[2] https://developer.apple.com/design/human-interface-guideline...

[3] https://littlegreenviper.com/miscellany/the-road-most-travel...

[4] https://www.iso.org/obp/ui/#search

[+] NKosmatos|3 years ago|reply

Came here to recommend the NN group. Plenty of free resources, guides and studies from the “godfathers” of UI/UX design :-)

[+] CornCobs|3 years ago|reply

What in your opinion doesn't work with UG testing?

[+] donohoe|3 years ago|reply

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.

The rest can follow after that.

[+] whitepoplar|3 years ago|reply

Cool! I'd love to know the things you've learned after dealing with real people. Can you share some with us?

[+] orthecreedence|3 years ago|reply

> What helped you increase your UX skills?

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.

[+] stayux|3 years ago|reply

Start with the fundamentals. I have published on my blog introduction series of articles for beginners (don't subscribe, it is not necessary).

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:)

[+] layer8|3 years ago|reply

In addition to what others have already mentioned, a lot can be learned from the old(!) Windows and OS X user interface design guidelines:

https://docs.microsoft.com/en-us/windows/win32/uxguide/guide...

https://apple.stackexchange.com/a/189487

[+] GuB-42|3 years ago|reply

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?

[+] SkyLemon|3 years ago|reply

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.

Good luck!

[+] sumtechguy|3 years ago|reply

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.

[+] hyperman1|3 years ago|reply

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.

[+] hyperman1|3 years ago|reply

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.

[+] mgkimsal|3 years ago|reply

> 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 :)

[+] unknown|3 years ago|reply

[deleted]

[+] eternityforest|3 years ago|reply

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.

[+] r_hoods_ghost|3 years ago|reply

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.

[+] pmontra|3 years ago|reply

> 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.

[+] nicbou|3 years ago|reply

> I try to think UI-first

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.

[+] pramodbiligiri|3 years ago|reply

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.

A couple of the recent older threads on this: https://news.ycombinator.com/item?id=29428533 and https://news.ycombinator.com/item?id=26932020

[+] jrockway|3 years ago|reply

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.

[+] dsmmcken|3 years ago|reply

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.

[+] lproven|3 years ago|reply

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.

[+] tahseen_kakar|3 years ago|reply

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

[+] stephencoyner|3 years ago|reply

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

[+] interleave|3 years ago|reply

In the past 2 years I learned to conduct and analyse in-depth interviews in the health-care sector.

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.

[+] yosamino|3 years ago|reply

That sounds very interesting - do you have some tips about how you learned this skill and how to do these interviews ?

[+] windows2020|3 years ago|reply

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.

[+] tuyenhx|3 years ago|reply

You dont have to read a lot of books about this topic.

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.

[+] wmeredith|3 years ago|reply

> Watch other people using, and improve.

This is the critical bit. Build-what-you-like only gets you so far.

122 comments