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?
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...
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.
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.
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.
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.
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
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.
React is arguably more about encapsulation, data flow, and state than about the fundamentals of UI and UX.
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.
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.
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.
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).
Also, The Non-Designers Design Book by Robin Williams.
And, I’m working through shiftnudge.com.
Everything by Tufte is worth reading.
The design of everyday things, Norman.
The humane interface, Raskin.
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...
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.