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...
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.
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.
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.
you could read more about this on my blog - https://medium.com/@Rutuja.Kelkar/how-i-started-my-ui-ux-des...
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.
Everything by Tufte is worth reading.
The design of everyday things, Norman.
The humane interface, Raskin.
Norman is ace. Although his books turned me into a usability weirdo unable to switch off my usability sensors... be careful! :-)
As is Raskin - whose interface "notation" (click-drag-click etc) I think isn't talked about enough.
Can I also throw in these...
Don't Make Me Think: https://www.amazon.co.uk/Dont-Make-Me-Think-Usability/dp/032... - I found this a REALLY useful book, and great to share with people too.
A Pattern Language https://www.amazon.co.uk/Pattern-Language-Buildings-Construc... - OK, this is a bit esoteric, but it's so valuable and lots of geeks/UX-ers kind of aim to create their own pattern language as opposed to a UX-dogma.
Information Architecture https://www.amazon.co.uk/Information-Architecture-Beyond-Lou...
Visual Language https://www.amazon.co.uk/Visual-Language-Global-Communicatio... - a kind of fundamental - hard to find.
--
There are dozens of methodologies to learn, and put into practice. I would put it that you don't really learn UX, you do it, and revise - in order to solve problems and make things better. Once you've digested some of the ideas you need to start trying the methodologies out. This is harder than it sounds. Even companies that claim to support UX, sort of bugger things up.... in that UX can't "fix" crap... it needs to be in at the beginning.
My favourite activities / methodologies, that produced REAL results were
* Ethnography - kinda just hanging out and observing what actually goes on. One client used to print off every page to proof read their changes cos the font sizes were designed by 21 year olds and they were 60+. The applause I got for raising the font size would never have been found any other way than sitting in the corner. * Card sorting - often collaboratively with armfuls of post its to decide on categories/navigation * Wireframing - I had less success with paper prototyping, but still ... * Personas + Use Cases
...and Eye Tracking - which tbh was SO VALUABLE, not because of the insights it provided, but for the EVIDENCE (video and heatmaps) that you could use to persuade the big wigs.
So find a way to start getting yourself into trying out various methodologies, to fix problems. Doing UX when things are "kind of OK" can be quite hard imo, especially at the beginning.
Your background will be so useful, again imo and experience, you will be able to use UX to provide guidance and ideas and then MAKE THE BLOODY THING which lots of UX-ers can't do. I liked the cross-over - I code a bit and sometimes found it easier to make what I wanted, rather than specifying it or creating "designs".
Good luck!
Tom
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).
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.
Also, The Non-Designers Design Book by Robin Williams.
And, I’m working through shiftnudge.com.
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.