[HN Gopher] Ask HN: How to learn UI/UX as a data/BE engineer?
___________________________________________________________________
Ask HN: How to learn UI/UX as a data/BE engineer?
Hi HN, coming from a data/ BE background I feel extremely familiar
with reasoning about systems and performance from the cloud-infra
to the pipeline stack level. Or I'm super familiar with data
visualization. I feel like falling off a cliff when trying to
extrapolate that knowledge to the more customer-facing world.
Despite having some tool ideas in the past, I realized I shy away
from going towards the front end because I really lack any
conecptual frame of how to think about and subsequently implement
UI or UX. I don't mean that in a nitty-gritty-designer focussed
way but more like first-principle understanding: What makes a good
color scheme? What makes a great wording and why? What's a good
form of presenting information? I feel like I can recognize good
UI/UX when I see it (as is often the case with HN company LPs), but
I'd totally fail at distilling check boxes that such good examples
tick. Any pointers to how I can learn about these worlds and
develop an understanding of what principles UI/UX should follow?
Author : thenaturalist
Score : 31 points
Date : 2024-10-21 15:22 UTC (7 hours ago)
| elawler24 wrote:
| The best way to get started is to use a trusted design system on
| the frontend, and follow their components, layouts, and color
| scheme exactly. Once you know the rules and have something basic
| implemented, you can break the rules from there. I think most
| developers go wrong when they try to re-invent the wheel before
| inherently understanding the rules (by copying experts).
| Tailwind, Google Material Design, and Apple UI interface are good
| starting points that are well documented.
| 8organicbits wrote:
| I think this is key, pick a good design system and it will cut
| down on how much you need to learn and tinker with.
|
| Personally I like plain HTML and Django templates, styled using
| Bulma components. I don't think about color, other than the
| high level "warning, danger, info" level. I don't think about
| spacing other than the "m-2 m-3" granularity. I don't mess with
| react, node, etc.
|
| This approach helped me launch backend oriented websites,
| without needing to be a FE expert.
| sargstuff wrote:
| 'The what' falls under the general domain of humanities
| art/architecture.[0]
|
| Staying within the bounds of data/be engineer aka the how, on-
| line courses / domain specific language use cases aka css, html
|
| [0] : https://www.springboard.com/blog/design/ux-design-
| principles...
| ninjha01 wrote:
| I really like this short book: https://www.refactoringui.com/
| d--b wrote:
| The authors created Tailwind after writing it.
| wg0 wrote:
| It is a short and good read.
| solardev wrote:
| Came here just to look for and upvote this book :)
|
| It's a great, short primer for anyone who needs to do a bit of
| light UI design as part of their job, but doesn't necessarily
| want to become a UX/UI specialist.
|
| It's one of the best resources I've come across as a FE dev.
| willio58 wrote:
| > I shy away from going towards the front end because I really
| lack any conceptual frame of how to think about and subsequently
| implement UI or UX.
|
| UX isn't a true requirement for frontend dev. Tech people
| (including myself) complain a lot about bad UX, and it's great
| you're interested but I just want to make sure you're not
| creating a false idea of dependency there. You can learn how to
| build UI without understanding the art of creating the best user
| experience for a problem.
|
| UX is a discipline in itself and it's something a frontend dev
| naturally learns about over time, and if you value it I say
| totally learn it! But if you're a backend dev wanting to get into
| frontend, just get into frontend and get into UX later.
| andrei_says_ wrote:
| Despite being bundled together, UX and UI are quite different.
| The problem space is also quite large.
|
| UI-wise I second the recommendation of starting with an existing
| component library. Bootstrap is still a good start.
|
| UX-wise - which would be the process of determining the process,
| I recommend taking a look at the "breadboarding" approach as
| described here.
|
| https://basecamp.com/shapeup/1.3-chapter-04
|
| For this, all you need is pen and paper. The process is low
| fidelity, cheap, and lets you quickly flesh out your ideas toward
| concrete screens at which point you can reach out for the
| component library.
| Neff wrote:
| As others have mentioned, there are differences between UX and
| UI.
|
| On the UX side, the main goals are to
|
| 1. Understand the needs of the user
|
| 2. Understand psychological principles of perception and
| cognition.
|
| 3. Present the information in a way to enable the user to
| accomplish their task with the least cognitive load possible
| (typically.. there are edge cases where you want to introduce
| more friction but we will ignore those for now)
|
| Start by getting a good understanding of the core Gestalt
| principles - https://careerfoundry.com/en/blog/ui-design/what-
| are-gestalt... - which influence how people perceive things.
| These principles are a core building block for UX and need to
| become an instinctive tool you use for arranging information and
| interfaces to achieve specific goals.
|
| From there I'd suggest reading the following
|
| - Don't Make Me Think by Steve Krug
|
| - The Design of Everyday Things by Don Norman
|
| - Everything by Edward Tufte, which as a data person you might
| have already read
|
| Getting a foundation of understanding how people process their
| world will be crucial to growing a UX competency. The color and
| wording part will come after that foundation is built.
| austin-cheney wrote:
| Design and usability are skills that take years of practice to
| mature. Its something vaguely akin to interior design. To learn
| that I would recommend reading books about visual design and
| taking art classes.
|
| To start you need to learn how the code works. But about the code
| you must first make a very deliberate decision:
|
| * Do you want to learn this for yourself?
|
| * Or, are you looking for employment?
|
| If the goal is employment then if you have a Java background
| learn Angular, otherwise learn React. They are massive
| frameworks, so its really just a matter of using the world's
| largest tools to put text on screen. Watch videos online. Be
| prepared for a lot of boring instruction that feels like
| copy/paste.
|
| If the goal is to learn this just for your own personal use then
| don't even bother with the framework nonsense. Its an inch deep
| just to people under-qualified people into the workforce and will
| become all consuming. Instead learn the event model for
| interaction, accessibility for how to write the markup, CSS how
| to make it pretty, and the DOM for how all this works together.
| Its more complicated than it sounds to get started, but once you
| achieve the smallest level of comfort its astonishingly faster to
| learn than the framework nonsense, because the framework nonsense
| is much larger than the things it layers over.
| changing1999 wrote:
| The least effective FE engineers I worked with (big tech) are
| people who learned client-side tech by learning React. They
| have a very limited understanding of UI concepts and an
| insufficient attention to detail.
|
| React is arguably more about encapsulation, data flow, and
| state than about the fundamentals of UI and UX.
| austin-cheney wrote:
| Agreed, but employment in software is not about
| effectiveness. Its about conformity. That is why the decision
| is a forced dichotomy.
| changing1999 wrote:
| That's an overly pessimistic view. Both professional and
| personal growth depend on effectiveness. Even conformity
| doesn't exclude it. You can conform better by being more
| effective.
| austin-cheney wrote:
| What if instead it were about shifting direction in favor
| of what is deterministic in response to numeric measures?
| For example instead of doing what feels comfortable as
| necessary to lower the perceived cost of hiring/training
| what if the focus were on building things that execute
| faster, achieve superior accessibility, or lower the cost
| to refactor according to automated analysis? Excellence
| is exclusive to those who wish to achieve it while
| conformity is the opposite.
| dotBen wrote:
| How would you explain to a UI/UX designer how to do the data and
| BE work that you do?
|
| As someone who has been a hiring manager for both roles I would
| suggest that they are reasonably different skillsets and
| personalities and not sure there's a high degree of overlap. If
| you fall into one camp I think it's better to hire for the other
| than to try to do both, assuming you are trying to achieve any
| kind of higher-order quality of work product.
| drcongo wrote:
| Back in the day there was no better resource than the Apple Human
| Interface Guidelines. I've not read it in years but the design of
| the OS on my Mac makes me suspect it's either no longer such a
| rich vein, or no longer exists at all.
| vant wrote:
| I recommend focusing first on UX as it applies to areas that are
| closest to your expertise. Not a good idea to go head first into
| art history, color theory, typography or concepts that are so far
| removed from what you're doing that would feel alien.
|
| Try starting a conversation with a FE engineer friend or even
| better with a UX engineer / design technologist if you know one.
| They speak both languages :)
|
| If you prefer reading, NNgroup is great for basics. Start with
| their 10 usability heuristics:
| https://www.nngroup.com/articles/ten-usability-heuristics/
|
| These 3 books should give you some great starting points:
|
| About Face - The Essentials of Interaction Design:
| https://www.wiley.com/en-gb/About+Face%3A+The+Essentials+of+...
|
| Design of Everyday Things:
| https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
|
| Creative Selection:
| https://www.goodreads.com/book/show/37638098-creative-select...
| codr7 wrote:
| I find that many designers are sadly missing a solid foundation.
|
| Everything by Tufte is worth reading.
|
| The design of everyday things, Norman.
|
| The humane interface, Raskin.
| changing1999 wrote:
| I highly recommend to start by building a very simple website
| from scratch using HTML and CSS.
|
| It's very common today for FE engineers to have a very limited
| understanding of the basics because they picked up client-side
| tech by following React tutorials (or any other highly abstracted
| framework).
|
| It's a very incremental learning process, so expect your brain to
| take some time to learn to identify small details that make great
| UI/UX. It takes practice!
|
| Once you feel comfortable building a simple page, explore various
| techniques to make it feel more professional (i.e. identify why
| your page doesn't look as good as some other references, and
| start copying their ideas).
| brailsafe wrote:
| I'd say the most important things to take away from other top
| comments here are the classic book recommendations, but other
| than that I'd argue any online sources should be secondary to
| watching people use systems for a few months based on training
| that's written or goven by someone else.
|
| I'm a frontend person, started in graphic design, and I've never
| actually been very good at design, but now I'm doing straight up
| IT work in an office with visibly stressed people using computer
| systems I did the hardware setup for, but not the software. These
| are all basic Windows laptops with pre installed images and
| cumbersome auth flows. Being in this job has offered me more
| insight than any article I've ever read, so therefore I think
| it's better to have some observation or hallway testing
| experience before looking to refine that with any specific UI
| recommendations or UX strategies that are rooted in theory.
|
| That's why I love the classic Don Norman book, because it's
| rooted in watching people use everyday objects that have been
| designed at a remove from their real world context. Just watch
| people use your shitty startup webapp UI or corporate hellscape
| portal, under stress for half an hour
| oumua_don17 wrote:
| https://www.learnui.design
| catchmost wrote:
| Similar background here. I think what made it <<click>> into
| place for me was the notion of metaphors and mental models.
|
| When someone (remember to define who!) looks at your app, they'll
| subconsciously build a map/model of how your system works. This
| model doesn't have to be accurate nor complete, and very often it
| certainly doesn't match your system model and architecture
| diagrams. But it needs to be good enough for the user to get
| their task done. Example: many devs think of a git repo as a tree
| of commits, and they mostly get the job done even if that's not
| at all how git actually works.
|
| The challenge then becomes to communicate a sufficient mental
| model with the minimal amount of effort on the user's part. (You
| could write a user manual or an interactive onboarding tutorial,
| but let's be honest nobody is going to read that.)
|
| How? Reduce the burden by explaining in terms of things they
| already understand. Examples:
|
| * Practically all UI toolkits come with buttons that resemble
| real-life physical buttons. You don't need to read the label or
| anything else to recognise that pressing it will trigger an
| immediate action. * A bus ticket app will visually display the
| ticket in a design that resembles a paper ticket. This helps
| drive home the point that <<this box with a QR code in it is just
| like having a ticket in your hand>>.
|
| A lot of design work can be seen as mapping out first what the
| users need, then how to communicate to them through the UI how
| your system can help them achieve whatever they want to do. This
| involves finding users and asking them a boatload of questions to
| understand how they think, what they really need. And also
| whether your UI communicates a sufficient mental model (don't
| contaminate their minds by explaining your UI!) and how to fix it
| when it's inevitably not correct on the first attempt.
|
| After all that, you can start worrying about colors. There's lots
| of good recommendations here already, highly recommend both
| reading some of the books and observing some real users trying
| real systems for the first time afterwards.
| mattkevan wrote:
| UX and UI are quite different, and are different again to visual
| design.
|
| UX is about understanding who your users are and what the
| problems they're trying to solve are, then organising flows,
| content and layouts to help them achieve it.
|
| I'd recommend reading Lean UX by Jeff Gothelf as it's a good
| introduction to a flexible, user-centred approach to product
| design.
|
| I've heard good things about the Google UX course on Coursera if
| you want to go into more detail. Interaction Design Foundation
| and Baymard Institute have a lot of great information.
___________________________________________________________________
(page generated 2024-10-21 23:01 UTC)