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 :)
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.
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.
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.
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.
Hey, the best way to learn UI UX is to do a project with a friend (or make online friends in a community like 10k designers) who is already at a good level at UI UX. This friend will guide you through entire process of learning and designing . Make sure to communicate your new to UI UX to your friend. I'm from data background too and I learnt UI UX by doing an end to end project - fitness App with my friend who knew UI UX thoroughly.
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.
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.
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.
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.
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.
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
I came here to say the same thing exactly. Tufte books are very visual (and expensive - see if you can find a copy of any of his books, changed my life). You can just dip in.
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.
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".
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.
> 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.
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).
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.
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.
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.
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...
I really like this short book: https://www.refactoringui.com/
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.
It is a short and good read.
The authors created Tailwind after writing it.
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.
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.
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.
Hey, the best way to learn UI UX is to do a project with a friend (or make online friends in a community like 10k designers) who is already at a good level at UI UX. This friend will guide you through entire process of learning and designing . Make sure to communicate your new to UI UX to your friend. I'm from data background too and I learnt UI UX by doing an end to end project - fitness App with my friend who knew UI UX thoroughly.
you could read more about this on my blog - https://medium.com/@Rutuja.Kelkar/how-i-started-my-ui-ux-des...
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.
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.
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.
Agreed, but employment in software is not about effectiveness. Its about conformity. That is why the decision is a forced dichotomy.
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.
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.
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
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.
I came here to say the same thing exactly. Tufte books are very visual (and expensive - see if you can find a copy of any of his books, changed my life). You can just dip in.
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
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.
> 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.
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).
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.
'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...
I agree that Refactoring UI is good.
Also, The Non-Designers Design Book by Robin Williams.
And, I’m working through shiftnudge.com.
https://www.learnui.design
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.
uxcel is a good place to start
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.