[HN Gopher] Ask HN: How did you increase your UX skills?
___________________________________________________________________
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?
Author : staticBr
Score : 139 points
Date : 2022-07-19 05:48 UTC (1 days ago)
| onion2k wrote:
| _What helped you increase your UX skills?_
|
| 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.
| matwood wrote:
| 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.
| z3t4 wrote:
| Getting feedback from users... And looking at statistics (what
| they don't tell you will show up in quantity analysis)
| lifeplusplus wrote:
| My story/Ted-talk on how I a dev learned design:
|
| 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
| tuyenhx wrote:
| 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 wrote:
| > Watch other people using, and improve.
|
| This is the critical bit. Build-what-you-like only gets you so
| far.
| carapace wrote:
| Read "Humane Interface" by Jef Raskin.
|
| https://en.wikipedia.org/wiki/The_Humane_Interface
|
| https://archive.org/details/humaneinterfacen00rask
| acarabott wrote:
| 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.
| donohoe wrote:
| 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 wrote:
| Cool! I'd _love_ to know the things you 've learned after
| dealing with real people. Can you share some with us?
| zichy wrote:
| Question yourself every step of the way if you are creating
| barriers for anyone.
|
| To get your started, I recommend this short summary about
| universal design, inclusive design, and accessibility:
|
| https://sayyeah.com/digital-insights/universal-design-access...
| tahseen_kakar wrote:
| 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
| staticBr wrote:
| @tahseen_kakar: Thanks for the reply! Are there any classes /
| seminars you can recommend?
| SkyLemon wrote:
| 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 wrote:
| 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.
| sonofhans wrote:
| 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.
| mmcdermott wrote:
| There are days where I would (somewhat tongue in cheek) say
| that UX is more anthropology than psychology.
| Wistar wrote:
| 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.
| sonofhans wrote:
| 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."
| mattferderer wrote:
| 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.
| btbuildem wrote:
| Context and workflow, 1000x
| [deleted]
| sneusse wrote:
| 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.
| stayux wrote:
| 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 wrote:
| Great context! Do you have any books you can recommend to
| become better at thinking/working in these ways?
| sonofhans wrote:
| "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.
| niccl wrote:
| 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.
| steve_adams_86 wrote:
| 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.
| sonofhans wrote:
| > 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.
| blackRust wrote:
| Personally, I found this book very useful and straightforward. It
| is written by the creators of Tailwind CSS.
|
| https://www.refactoringui.com
| vladstudio wrote:
| Lots of great comments here. I'd like to add something
| unexpected: story-telling (or, creative writing).
|
| 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.
| game_the0ry wrote:
| Call me stupid, but I just pick a really good css framework and
| either try to copy and / or learn from it.
|
| Tech companies with great engineers and designers have given away
| these for free. I try to stand on their shoulders.
| jaredlt wrote:
| I loved the book Don't Make Me Think by Steve Krug
|
| Sort, simple and insightful.
|
| https://sensible.com/dont-make-me-think/
| occz wrote:
| UX is merely the functional side of designing things, and the
| best resources to help me understand that has been:
|
| - The book The Design of Everyday Things - The podcast 99%
| Invisible
| jrockway wrote:
| 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.
| mcjiggerlog wrote:
| Honestly, like with most skills, practice. Build lots of
| interfaces and complex interactions and you will get better at it
| over time.
| swyx wrote:
| study and compile every bit of advice that people hand out and
| make it easy to retrieve on demand:
|
| https://github.com/sw-yx/spark-joy
| stephencoyner wrote:
| 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
| layer8 wrote:
| 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 wrote:
| 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?
| spaetzleesser wrote:
| 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.
| windows2020 wrote:
| 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.
| bitwize wrote:
| 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.
| freedomben wrote:
| 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.
| orthecreedence wrote:
| > 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 wrote:
| 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:)
| rad_gruchalski wrote:
| 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.
| kareemm wrote:
| 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 wrote:
| Your site is down buddy
| xupybd wrote:
| Yeah it's not a great user experience currently. I think the
| problem is a typo. There is a website without the www that
| works.
|
| http://trialtopaid.com
|
| It's an instant redirect to another domain.
| asdjfhjlaksdhf wrote:
| links broke
| hoofhearted wrote:
| https://tailwindui.com/components
| pramodbiligiri wrote:
| 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
| will5421 wrote:
| Make something, then forget about it until you need to use it.
| Forgetting is the important part.
| ChrisMarshallNY wrote:
| 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 wrote:
| Came here to recommend the NN group. Plenty of free resources,
| guides and studies from the "godfathers" of UI/UX design :-)
| hyperman1 wrote:
| 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.
| mgkimsal wrote:
| > 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 :)
| hyperman1 wrote:
| 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.
| [deleted]
| zafka wrote:
| I think all developers hardware and software should read "Design
| for Everyday Living" <SP> https://www.amazon.com/Design-Everyday-
| Things-Revised-Expand...
| feral wrote:
| 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!)
| palmm wrote:
| https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
|
| The Design of Everyday Things by Don Norman
| jasfi wrote:
| Good tools help a lot, by that I mean frameworks and libraries,
| e.g. for CSS.
| cpursley wrote:
| I've gotten a lot of mileage out of following Victor Ponamariov:
|
| - https://user-interface.io
|
| - https://hundred.user-interface.io <- this is especially good
|
| - https://twitter.com/vponamariov <- he often has great threads
| interleave wrote:
| 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.
| labratmatt wrote:
| 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.
| throwaway0asd wrote:
| 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.
| efortis wrote:
| 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."
|
| - Douglas Engelbart
| eternityforest wrote:
| 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 wrote:
| 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.
| nicbou wrote:
| > 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.
| sbmthakur wrote:
| The case-studies by Growth.Design have been pretty helpful.
|
| https://growth.design/case-studies
| dsmmcken wrote:
| 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.
| bena wrote:
| 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.
| 1autodev wrote:
| 1. Learned ReactJS
|
| 2. Explored ReactJS component libraries & https://react.rocks/ .
| One of my favorites for data table UX: React Bootstrap Table -->
| https://react-bootstrap-table.github.io/react-bootstrap-tabl...
|
| 3. Copied and pasted
|
| 4. Edited code a little bit
|
| 5. Things worked
|
| 6. Finished project(s)
|
| 7. Breathed sigh(s) of relief
___________________________________________________________________
(page generated 2022-07-20 23:01 UTC)