Like a lot of you I have mostly worked in back-end or systems software. My CSS/UI/UX skills are very minimal. I get disheartened by how my project looks or don't start the project because I fear it would look crap or I despise doing the UI/UX work.
A lot of engineers have the mentality of "engineering is hard, but design is just whatever some color matching and styling".
I'll prob. be downvoted but here's my honest opinion: I think you'll gain a lot career-wise to learn about UX and UI. You'll be able to understand products in a deeper level from the customer's side and will then be able to make better decisions as an engineer. You'll also have a much easier time working with designers and PMs. And, of course, your projects will feel and look great.
IMHO, the biggest bang for the buck you could learn is:
- Visual hierarchy (I.e. the same way you divide your code in modules and functions, you need to divide the visual space in a clear hierarchy).
- Basic on typography (It makes a big difference even if most people don't notice it)
- Understanding what's UX (I.e. reading "Don't make me think"). Just "caring" and "thinking" about UX will improve designs, even if you don't have much experience.
- Basic of color theory; How different colors mean different things (Branding-wise or for alerts/errors/warning).
Reading material design from Google https://material.io is a great start. You may not like the UI of it, but the UX and explanations of why things are this way are really interesting.
* Visual hierarchy (I.e. the same way you divide your code in modules and functions, you need to divide the visual space in a clear hierarchy).
* Basic on typography (It makes a big difference even if most people don't notice it)
* Understanding what's UX (I.e. reading "Don't make me think"). Just "caring" and "thinking" about UX will improve designs, even if you don't have much experience.
* Basic of color theory; How different colors mean different things (Branding-wise or for alerts/errors/warning).
> A lot of engineers have the mentality of "engineering is hard, but design is just whatever some color matching and styling".
Just anecdata, but as an engineer I think engineering is easy and design is hard.
For engineering you just have to follow logic, reasoning, good practices and have discipline. Also you can test your code to death to make sure everything is correct.
I actually took a 3-month crash course on Visual Design because I was weak in that area (as a front-end developer). Probably one of the best professional investments I have made. The course taught me basically the above list.
I would add knowledge about grids and negative spacing to the above list.
Being on the software engineering side of things, I do not trivialize the design aspect. However, it's very rare that an 'engineering' type person will also have the 'ux/ui/designer' chops. We don't necessarily understand that aspect of things in the same way ... clearly my weakness, and I assume it as such.
Ideally software development in some case would benefit enormously in a holistic approach to the engineering and design side of things. I've been looking for a good designer to complement my set of skills, but I've yet to find that person...
I am really leaning towards taking a course in such design aspects. But I won't become a magical-ux-ui-designer wizard.
I've recently taken a design class and I have a keen interest in design in general, and I would say your suggestions are on the money.
I would also mention the importance of layout and flow line, or how will you organize your elements in the page and how will your audience traverse them visually? This is something you really ought to think about very hard.
> Basic on typography (It makes a big difference even if most people don't notice it)
Can you expand on why typography matters? I've never understood why some people seem to care so much about kerning and line angles in the glyphs and such. What do you think are the most important topics in typography people should learn and why do they matter?
I develop an internal product that is currently used only by our companies service technicians, but the end goal is to release this to our partners for use outside of the company. Here is one of the biggest things I've learned about UX as a non-designer: watch people use your products, and be ready to accept failure. Let's say you've designed something specifically to be used a certain way. Then, upon user testing, 5 people deliberately use it a different, unintended way. This is YOUR mistake, not theirs. It can be hard to predict these type of things in advance, I've found. As a programmer, I tend to think about software a completely different way than a non-programmer (especially someone in a non-technical role). This often results in software that I think is simple, but turns out is non-intuitive and complicated.
> Reading material design from Google https://material.io is a great start. You may not like the UI of it, but the UX and explanations of why things are this way are really interesting.
To add, I've found reading the design documentation of some web and mobile UI libraries to be very enlightening. For example, the colors section of BlueprintJS has helped really narrow down how I use colors: https://blueprintjs.com/docs/#core/colors
Came to the comment section to basically write the same thing. The design is more important than coding in many ways, it's truly what sells the product.
I've often used it to highlight working features and "hid" the less functional ones. I'm learning myself, but totally worth getting a basic grasp on it. I usually have my designer friends or colleagues provide feedback which helps me learn.
I am a physics PhD turned application programmer who got into systems programming the hard way.
My design skills are such that i can make something good probably half the time on my own.
You're right that a small investment in learning will get you some big gains.
One thing that helps is sticking to some standards. I worked at web dev shop that had a standard for forms that we called "Spider Forms" that might not have been genius but it is better than what you'd get without a plan and cheaper (and still better) than what you would get bikeshedding it with a client.
I like anime art because it designed to be easily reproducible by many people. I got good at drawing these
guys
It's the only character I can draw but I can draw them quickly on blackboards, whiteboards, etc. My son lately has learned how to draw characters from Starfox and Sonic.
I used to think about color theory but these days I just find a picture that has a color scheme I like and copy the color swatches.
I think many people would be better off if they stuck to a small set of fonts and did not think about typography. If people put a lot of effort into it they often end up doing worse than if they took the defaults. For me the really interesting aspects of typography are the "less travelled" paths such as "what do you do if the text is too big to fit in the space?" and then shoehorning it in by changing the letter spacing and squeezing the letters.
Then there is the rule of thirds. Learning that didn't make me into Ansel Adams but it vastly improved my photography overnight.
Really, I wouldn't recommend that theoretical approach at all to a backend engineer who wants practical tips for their side projects. I'd say something like:
- Learn to use bootstrap (or whatever the most highly-thought of equivalent batteries-included CSS framework is)
- Don't be scared of modern JS. Work through the tutorial on webpack: https://webpack.js.org/guides/getting-started/ And figure out how to incorporate it into your projects development work flow. Then you'll be able to write in modern JS and take your pick of JS frameworks to use if you want.
Funny thing is, I find that site virtually unusable. It's impossible to navigate. I can't figure out what sections there are or where the content is or if there's an order or relationship between articles.
The Material Design guidelines have terrible advice. There is way too much animation (bad for accessibility), and unbelievably garish color recommendations. Google's own implementation of MD have no aesthetic restraint and they are making their products unpleasant to use. The basic idea of MD is fundamentally flawed, because UIs shouldn't simulate physical motion for accessibility reasons.
Why I would spend time learning UI/UX when I can be 10X more productive building functionality. Designer even good one will charge you much less than your developer time.
Time for me to rant about how pointless and useless "color theory" is beyond the obvious things like red is for errors and green is for success. It's just a bunch of non-sequitors where people take random facts and then apply them after the fact on particular designs.
Things like trying to design using colors from swatches or using colors based on their position on the color wheel are examples of what not to do because the ideas behind them are often misunderstood and therefore poorly applied.
And don't even get me started on color psychology. For example, they'll take some fact like a lot of foods aren't blue or that some mould is blue and then say that's why you shouldn't use it for food related designs. Which is rubbish because you definitely want a nice blue for things like blue cheese, or for water related stuff. I could easily see someone thinking that having a picture of the ocean on a menu or part of their advertising is bad because of these silly articles even if that's their restaurant theme. It's not just about the color, but the overall design.
* Sketch out the idea on literal paper before committing it to working code. Paper is so much easier to get 'working'.
* Borrow visually from other sites that I like and have similar intent. I don't have the time on side projects to go crazy breaking new UX ground. (And users probably don't want that anyway.)
* Keep the idea simple and uncluttered. Maybe a specialist could get away with fancy stuff, but I'm not a specialist.
* Try to offload functionality into the back end. If I can simplify the user experience by making the back end more intelligent, I do it.
* Be very cautious about introducing technical complexity. Usually for side projects, I have a specific goal I want to achieve and limited time in which to achieve it. I'd rather not spend that time messing around with some fancy framework, unless I'm convinced I need it to satisfy my goal.
* Reuse from my other work.There are a lot of aspects of, say, a website, that don't have to be uniquely redone for each. So it might quickly become cost effective to factor out something like a login flow UX. (And has the benefit of offering some degree of consistency across projects...)
Several of these resonate with me and align with my past experiences.
* Create a paper/whiteboard design first.
* Borrower from other sites/past projects.
* KISS / minimize technical complexity.
Some might say Vue.js is technical complexity but after investing time to learn the basics I would say that I'm reaping productivity gains. Honestly it's great to work with and making UI's that have some degree of a pleasant user experience.
Here are two projects I've worked on recently where I've used Vue.js. The first is via Vue-Cli and a true SPA app that is hosted through Amazon S3 and CloudFront. The second an ASP.NET Core app hosted on Heroku as a container. In both cases, Bootstrap has integrated very well with the Vue.js app.
A driving factor for creating these has been to share my Vue.js knowledge with others.
I skip the draft step, but otherwise I am very similar.
Simple, extremely lean and functional tooling and extremely simplified frontend functionality.
If I can achieve good UX with CSS media queries and a light dusting of vanilla JS then that is all I will use. I also leverage new browser features where possible. The datepicker in some browsers suck, but it is native and I don't have to maintain it.
Awesome list. One point I’d add that changed how I think about UI and UX is being aware when UI reflects internal code structure instead of just doing what a user would want to see.
The latter is harder, so engineers tend to avoid it, often subconsciously.
I'm a ux designer and a professor in hci.
It looks like there is still a lot of confusion between UX and UI. UX is not just what concerns the interface.
UX is a process with different phases:
- an exploratory phase, where the designer interviews the stakeholders, analyzes the current product (if it is a redesign), makes a benchmark of the competing products and services;
- a research phase, where the designer involves actual or potential users to understand their needs, goals, their knowledge, their behaviors; she does interviews, observations, and uses methods like the laddering, the free listing, the card sorting, the task analysis and so on
- the raw results of the research are documented in a number of deliverables:
* personae
* scenarios
* customer journeys / experience maps
* conceptualizations
* taxonomies and navigation trees
- the research is translated into the design of the product, producing wireframes or low fidelity prototypes, designing the macro and the micro information architecture, the interaction, the navigation;
- a design system should be adopted and / or developed, identifying the components, the colors, the typography, the tone of voice
- a high fidelity prototype applies the design system to the low fidelity prototipes
- everything should be tested with the users, in different moments: competitive testing (to test the competitors' products), exploratory testing, confirmatory testing; prototypes should also be evaluated to verify the conformity to the standards and to the design system / style guides;
This is UX design (different experts will describe it in slightly different ways, but the structure remains the same).
I'm obviously aware that this process would be a big effort for a side project. But it's very important to keep in mind that this is the right approach, and in the long run, the process will decrease the risk of failure.
Good set of guidelines and thanks for sharing. But in reality not all projects can afford to go through this routine.
The following is what i believe works for most time sensitive projects. It would be better to set a top level vision for the UX and give it to proven people to deliver. UI/UX is something that everyone in an organization can have an opinion very easily so your goal should be to satisfy end user and not everyone in the company. Take it as early as possible to beta testers and if your initial vision for UX is solid - it would take few iterations to get it correct.
If you don't mind, could you explain what HCI is in your view as well? I think that's another discipline related to CS/UX/Design but is still quite distinct to those who understand it best.
If we're talking webapps, I tend to go to https://themeforest.net and buy HTML themes developed by professional designers. The cost is MUCH cheaper than hiring someone to develop the UI for you, and a lot of them are extremely high quality.
>Like a lot of you I have mostly worked in back-end or systems software. My CSS/UI/UX skills are very minimal.
I never came up with a special talent for UI/UX. I remember I had a friend who was web developer he was insanely talented , could make a sexy landing page in just a few minutes.
For me this has always been impossible , I immediately start thinking about optimizations, legacy browser support , CI/CD etc... Typical issues of system driven person....
A few years ago I realized I wasn’t like him and it was « Okay ».
I found out I can’t do « many side projects » at once nor frequently.
Instead I only build one project at a time but I do it properly. I design things out in Photoshop or Adobe XD where I usually spend weeks before coding anything.
The goal is really to be working in pure V Cycle where you don’t start Prototype unless you are done with the design.
Been using this technique ever since and I haven’t been frustrated ever since. Would recommend to try it with any design software that you like to work with.
The mistake that a lot of people make is thinking that it's a code/framework/tech problem it isn't.
Start by putting the technology aside, it only serves to bring your idea to life. Which bring us to the ideas...
Ideas are never 100% original. I challenge you to imagine an object of a shape and color not made from anything you've ever seen... it's impossible. What I'm saying is that you need to take inspiration from various sources. From this you'll be able to bring these elements together in a new way.
> The mistake that a lot of people make is thinking that it's a code/framework/tech problem it isn't.
A good framework and set of components can help a lot though. I'm building a mobile app at the moment using flutter, and the material components in that make it so much more efficient to build nice looking things that work well. Animated transitions between screens for instance can be really fiddly, but flutter has support for some useful ones out of the box using 'hero' widgets.
I've discovered that https://tailwindcss.com/docs/what-is-tailwind/ fits me best as a way to do UX/UI as a backend person. Feels like functional programming with well-defined, limited number of building blocks, whereas normal CSS styling always seemed like endless amount of options. Also the docs are really great with some ready-made patterns. No idea if it is for everyone but I enjoy it right now.
- Draw out a design using Sketch, draw.io or any other similar tool.
- Find a color scheme, I typically google for "flat UI colors" since I like them most. Adobe color wheel is also a great tool for finding complementary / shades of colors: https://color.adobe.com/create/color-wheel/
- Then I start prototyping my ideas, typically in react, using a CSS-in-JS lib such as styled-components, this allows for quick iteration.
- I do research. For example, I look at how other websites or UI component libraries do things. Examples are material UI, ant design, semantic UI.
The most important thing is refinement. You start with a rough sketch, prototype in react or HTML and then start playing around with the CSS. Learning all the css attributes definitely helps. Don't try and learn them all from a list, but just google them as appropriate and you'll start picking them up. For example, you might think: "How do I center the children elements both vertically and horizontally on different screen sizes?". A quick google search will suggest to use display: flex, justify-content: center, and align-items: center.
HTML & CSS is a commodity skill, and most of its mundane parts are going to be automated away soon. Either through a design-to-code workflow like what I'm working on now (https://protoship.io), or with integrated tools like Webflow & Modulz.
There are folks who're able to design in code (Basecamp style), folks who're only able to design in a drawing tool and does not know CSS at all (the Dribbble crowd), and the unicorns that I'm so jealous of who're able to play in both courts masterfully.
But knowing design doesn't have much to do with tools - HTML/CSS or Sketch. I've observed folks from all three categories, and my singular take-away was practice, practice, practice. Some people have an aesthetic bend that gives them an advantage, but most of us can build a basic understanding by being deeply interested in the craft and putting in the hours. Search for "how to be a designer", there is a rich array of resources. Pick a book like The Non-Designer's Design Book, an online course like refactoringui, and a DailyUI challenge. Start deliberate practice. Give it a few hundred hours.
Then buy a copy of Sketch and draw a couple of phone screens (by hand) [1, 2]. The idea is to do it by eye, so no cheating by using color pickers or measuring the pixels, do it by eye. Draw all the icons. In actual projects you can use icons but now you have the power to create your own.
Then do this one (the image)[3]. Now you should be on the level that you could draw any figure well enough as long as you have a reference image for it.
In my opinion regarding UI design there's no need to go further than this if it is purely for your own projects. The idea is to create a nice looking UI, not photo realistic images by hand ;)
[2]: Sketch quick start: press A (for artboard) to plop down a screen. With R (rectangle) and O (oval) you can create simple figures. With V (vector) you can do the pen tool thingy that you've trained at bezier.method.ac. The rest should make sense on its own.
I learned design + frontend engineering together. My side project turned into my full-time startup: https://www.cacher.io
The best advice I can give in terms of managing UX:
0. Get Sketch (https://www.sketchapp.com) and use one of its UI kits (https://www.sketchappsources.com) to lay out your designs. While you should pay attention to visual details, you won't need to lay out every state since you won't be showing these to anyone else.
1. Build your project with one of the established frameworks (Material is pretty good). This will give you a sense of visual hierarchy and force you to think about why elements are placed where they are.
2. Introduce your own modifications and controls as needed. Even with a framework, you'll eventually come across a use-case that isn't readily handled.
3. Keep your modified framework in its own folder/repo. Continually update it as visual standards/technologies change. Doing this will cut down on the amount of re-work necessary when you're starting new projects.
Do you have any suggestions on how to learn Sketch? I've downloaded it but don't really know how to get started. YouTube videos? Or, are there people writing about using it, starting from the developer mindset?
This used to be a pain in the ass for me, but the beginning of this I rewrote everything from scratch including the UI. Now I have everything automated behind a build. All of my options, their configuration, and all corresponding documentation is built from a single simple config.
To automate this properly so that user performance is fast and maintenance is simple you don't need any frameworks or tooling. You just need a good plan and a proper organization of things.
About 80% of the user interactions are built from automation. There is some manual wiring that has to occur for various things where interactions are unique to a given option. The manual interaction stuff wasn't too bad when I wrote the code this past spring and it requires almost no maintenance. All the stuff that would be a pain the ass to keep up with is fully automated.
The best solution is to learn graphic design. Most engineers make the similar mistakes when starting out, so here's a cheat sheet:
* Your colors are too saturated, desaturate everything. (If you're using LCH, make 50 chroma your default for something that's "colorful.")
* Use more padding, more whitespace, and bigger fonts. Increase it until you're starting to get uncomfortable, then increase it just a little more past that.
* Remove everything you can remove, or if you can't bare to do that, relegate it to a dumpster page like an "about" section. Use the extra space this frees up for more whitespace.
* Whenever you think something needs more X, consider making everything else less X instead.
* If you're using LCH, you can do color theory by the numbers instead of eyeballing it. e.g. add 180 to the hue to do complimentary colors. This is not true of HSV.
* Establish a consistent visual hierarchy to group your content. Expect this to be the hardest part; even the best designers brute force this. The top of your hierarchy should frequently be the least emphasized part.
I don't; my side projects have the shittiest UIs ever.
For things that make money, I just hire a professional. There have been times where I have put a lot of personal time into improving a UI. What ends up happening is that that time ends up being a total waste of time because the UI/UX professionals are able to do the same work in a fraction of the time. It's almost never a waste of money, either.
This is definitely a problem for a lot of people. When I was in grad school, I used to go to Hackathons a lot, build a cool working backend, but a ugly front end which just does the job and I never won anything until I forced myself to learn Angular and used bootstrap themes to scaffold a basic UI/UX.
Unless you have a friend who happens to be a front end engineer and who wants to work on side projects along with you, the best solution is to learn just enough to get by. Learn react or angular and learn how to customize existing free themes available out there.
I started with C++ and Arduino, then learned all the way through the basics of design. Including UI, and now I'm learning/improving User Testing (UX) since I have learned the more technical parts of UX long time ago. Graphic design is still out of reach for me though, since I know I'd have to spend hundreds of hours learning all about design to use a small part in web (which is not a high enough ROI for me). I have a very good friend that is very awesome at it, so in case of need I can always go to him.
It's been a great ride, and unfortunately impostor syndrome hits from time to time both on the front-end and the back-end (quite ironic). Though it's been fairly mild/easy to handle, I've had a lot of external validation through the years.
If you decide to learn it as your main learning focus (let's say, 15-20h/week), you could become fairly decent in 6 months-1 year. Then you can become quite good within 3-4 years. There are quite a few branches and ways to go about learning though, so if you want to learn I'd recommend searching and getting informed, but I deeply believe in the quantity above quality: https://blog.codinghorror.com/quantity-always-trumps-quality...
1 - Learn the basic principles (see d0m's comment).
2 - Borrow/copy like crazy from others who are better than you.
3 - Be brutally honest with yourself and know your limits. You don't need to be a brilliant designer to achieve that magical "good design" effect--you just need to get the fundamentals right and avoid mistakes. Until you develop some instincts, most of the ideas you have won't work, so you need to be willing to throw out what you've done and try again ad infinitum. If in doubt, take it out.
Last point: I think it's close to essential knowledge at this point for building viable software products. Like it or not, people judge by appearances, and good design is one of the best levers available to make people take what you're doing seriously. It's one of the top things that can take you from being perceived as a "hobby project" to being perceived as a "startup".
It's not easy to learn, but it's not really that hard either in the scheme of things, and it pays massive dividends. Even if you're using templates or paying someone else to do it, you still need to be able to distinguish the good from the bad if you want to avoid the (often subtle) mistakes that kill the perception of quality.
I'm not too bad at front-end development (especially if someone else does the design and mockups), but I don't have great design or UX skills.
I really like starting with balsamiq for mockups, because I can figure out the functionality and don't have to think too much about the design. And then I like to use a UI framework with a set of pre-built components, and maybe a theme. Bootstrap is great for that, and you can get some great themes so that it doesn't look like a "bootstrap" site.
My favorite UI framework is Ant Design [1], because they have an amazing set of React components that are really nice to work with. I was blown away when I discovered Ant Design Pro [2] (which is free!). It's an "out-of-box UI solution for enterprise applications". Basically a fully featured dashboard built with Ant Design, including things like authentication pages, charts, etc. Everything you need for a side project, and it's easy to strip away all the stuff you don't want.
Sounds like you're on the right path in that you have a genuine desire to create great looking products. This means you have a respect for design, which is hugely important.
I used to be a back-end guy (I once co-authored a book on an ORM and just love middle tier and db shizzle). I had a huge appreciation for products that looked and felt great, but only had the back-end skills. I had a genuine desire to build skills in design so I could make better products.
If you want to take some short-cuts to build great looking stuff I'd do the following
- Build a mood board of stuff you think looks great. Set your own standards bar.
- Play around with Sketch or similar to learn how to get the look you like (this will make you think about UI design problems). This might take years but you have to start somewhere.
- Read "Design of Everyday Things" and "Don't Make Me Think" and a few other design classics. The principles stand strong.
- Get help from designers to bridge the gap between your skill level and where you want to be. When I started my company, I'd find designers who had a visual style I liked and paid them to help out.
I use a framework - I like Semantic UI a lot, although I'm not sure it's being maintained. When selecting a framework, I like to resize the browser to see how responsive it is, and look for text overlap defects at different sizes as a sign of library quality.
Adobe XD is also a free prototyping tool - I would go through a tutorial or watch a few youtube videos of people working to get a feel for it.
[+] [-] d0m|7 years ago|reply
I'll prob. be downvoted but here's my honest opinion: I think you'll gain a lot career-wise to learn about UX and UI. You'll be able to understand products in a deeper level from the customer's side and will then be able to make better decisions as an engineer. You'll also have a much easier time working with designers and PMs. And, of course, your projects will feel and look great.
IMHO, the biggest bang for the buck you could learn is:
Reading material design from Google https://material.io is a great start. You may not like the UI of it, but the UX and explanations of why things are this way are really interesting.[+] [-] andrei_says_|7 years ago|reply
* Visual hierarchy (I.e. the same way you divide your code in modules and functions, you need to divide the visual space in a clear hierarchy).
* Basic on typography (It makes a big difference even if most people don't notice it)
* Understanding what's UX (I.e. reading "Don't make me think"). Just "caring" and "thinking" about UX will improve designs, even if you don't have much experience.
* Basic of color theory; How different colors mean different things (Branding-wise or for alerts/errors/warning).
[+] [-] sfilargi|7 years ago|reply
Just anecdata, but as an engineer I think engineering is easy and design is hard.
For engineering you just have to follow logic, reasoning, good practices and have discipline. Also you can test your code to death to make sure everything is correct.
For design you have to have an artistic nature.
[+] [-] ohkaiby|7 years ago|reply
I would add knowledge about grids and negative spacing to the above list.
[+] [-] kelvin0|7 years ago|reply
[+] [-] plainOldText|7 years ago|reply
I would also mention the importance of layout and flow line, or how will you organize your elements in the page and how will your audience traverse them visually? This is something you really ought to think about very hard.
Also, learn about gestalt principles. For example: https://www.howdesign.com/resources-education/online-design-...
[+] [-] jolmg|7 years ago|reply
Can you expand on why typography matters? I've never understood why some people seem to care so much about kerning and line angles in the glyphs and such. What do you think are the most important topics in typography people should learn and why do they matter?
[+] [-] SomeCollegeBro|7 years ago|reply
[+] [-] etxm|7 years ago|reply
People that are good at it are like majestic unicorns to me.
[+] [-] chaostheory|7 years ago|reply
This mentality died over a decade ago, especially given the rise of Apple and the mainstream awareness of Jobs as a design guru
[+] [-] ioddly|7 years ago|reply
To add, I've found reading the design documentation of some web and mobile UI libraries to be very enlightening. For example, the colors section of BlueprintJS has helped really narrow down how I use colors: https://blueprintjs.com/docs/#core/colors
[+] [-] lettergram|7 years ago|reply
I've often used it to highlight working features and "hid" the less functional ones. I'm learning myself, but totally worth getting a basic grasp on it. I usually have my designer friends or colleagues provide feedback which helps me learn.
[+] [-] PaulHoule|7 years ago|reply
My design skills are such that i can make something good probably half the time on my own.
You're right that a small investment in learning will get you some big gains.
One thing that helps is sticking to some standards. I worked at web dev shop that had a standard for forms that we called "Spider Forms" that might not have been genius but it is better than what you'd get without a plan and cheaper (and still better) than what you would get bikeshedding it with a client.
I like anime art because it designed to be easily reproducible by many people. I got good at drawing these guys
http://hyperdimensionneptunia.wikia.com/wiki/Dogoo
It's the only character I can draw but I can draw them quickly on blackboards, whiteboards, etc. My son lately has learned how to draw characters from Starfox and Sonic.
I used to think about color theory but these days I just find a picture that has a color scheme I like and copy the color swatches.
I think many people would be better off if they stuck to a small set of fonts and did not think about typography. If people put a lot of effort into it they often end up doing worse than if they took the defaults. For me the really interesting aspects of typography are the "less travelled" paths such as "what do you do if the text is too big to fit in the space?" and then shoehorning it in by changing the letter spacing and squeezing the letters.
Then there is the rule of thirds. Learning that didn't make me into Ansel Adams but it vastly improved my photography overnight.
[+] [-] Myrmornis|7 years ago|reply
- Learn to use bootstrap (or whatever the most highly-thought of equivalent batteries-included CSS framework is)
- Don't be scared of modern JS. Work through the tutorial on webpack: https://webpack.js.org/guides/getting-started/ And figure out how to incorporate it into your projects development work flow. Then you'll be able to write in modern JS and take your pick of JS frameworks to use if you want.
- Don't be distracted by all the blog posts.
[+] [-] aerovistae|7 years ago|reply
[+] [-] JoshMnem|7 years ago|reply
[+] [-] mukeshsoni|7 years ago|reply
It went through exactly the points you mention in good detail. And she also showed implementation of some of these ideas on the web.
[+] [-] Chyzwar|7 years ago|reply
[+] [-] msaharia|7 years ago|reply
[+] [-] laksmanv|7 years ago|reply
[+] [-] wpmoradi|7 years ago|reply
[+] [-] bytematic|7 years ago|reply
[+] [-] madeuptempacct|7 years ago|reply
[deleted]
[+] [-] preommr|7 years ago|reply
Time for me to rant about how pointless and useless "color theory" is beyond the obvious things like red is for errors and green is for success. It's just a bunch of non-sequitors where people take random facts and then apply them after the fact on particular designs.
Things like trying to design using colors from swatches or using colors based on their position on the color wheel are examples of what not to do because the ideas behind them are often misunderstood and therefore poorly applied.
And don't even get me started on color psychology. For example, they'll take some fact like a lot of foods aren't blue or that some mould is blue and then say that's why you shouldn't use it for food related designs. Which is rubbish because you definitely want a nice blue for things like blue cheese, or for water related stuff. I could easily see someone thinking that having a picture of the ocean on a menu or part of their advertising is bad because of these silly articles even if that's their restaurant theme. It's not just about the color, but the overall design.
[+] [-] mschaef|7 years ago|reply
* Sketch out the idea on literal paper before committing it to working code. Paper is so much easier to get 'working'.
* Borrow visually from other sites that I like and have similar intent. I don't have the time on side projects to go crazy breaking new UX ground. (And users probably don't want that anyway.)
* Keep the idea simple and uncluttered. Maybe a specialist could get away with fancy stuff, but I'm not a specialist.
* Try to offload functionality into the back end. If I can simplify the user experience by making the back end more intelligent, I do it.
* Be very cautious about introducing technical complexity. Usually for side projects, I have a specific goal I want to achieve and limited time in which to achieve it. I'd rather not spend that time messing around with some fancy framework, unless I'm convinced I need it to satisfy my goal.
* Reuse from my other work.There are a lot of aspects of, say, a website, that don't have to be uniquely redone for each. So it might quickly become cost effective to factor out something like a login flow UX. (And has the benefit of offering some degree of consistency across projects...)
[+] [-] hnrodey|7 years ago|reply
* Create a paper/whiteboard design first.
* Borrower from other sites/past projects.
* KISS / minimize technical complexity.
Some might say Vue.js is technical complexity but after investing time to learn the basics I would say that I'm reaping productivity gains. Honestly it's great to work with and making UI's that have some degree of a pleasant user experience.
Here are two projects I've worked on recently where I've used Vue.js. The first is via Vue-Cli and a true SPA app that is hosted through Amazon S3 and CloudFront. The second an ASP.NET Core app hosted on Heroku as a container. In both cases, Bootstrap has integrated very well with the Vue.js app.
A driving factor for creating these has been to share my Vue.js knowledge with others.
* https://github.com/ryanrodemoyer/ParlayTools - available @ https://d3itp7yns2kqcy.cloudfront.net
* https://github.com/ryanrodemoyer/AccrualCalculator available @ https://accrual-calculator-prod.herokuapp.com
Good luck!
[+] [-] ehnto|7 years ago|reply
Simple, extremely lean and functional tooling and extremely simplified frontend functionality.
If I can achieve good UX with CSS media queries and a light dusting of vanilla JS then that is all I will use. I also leverage new browser features where possible. The datepicker in some browsers suck, but it is native and I don't have to maintain it.
[+] [-] paulftw|7 years ago|reply
The latter is harder, so engineers tend to avoid it, often subconsciously.
[+] [-] sweetdreamerit|7 years ago|reply
- an exploratory phase, where the designer interviews the stakeholders, analyzes the current product (if it is a redesign), makes a benchmark of the competing products and services;
- a research phase, where the designer involves actual or potential users to understand their needs, goals, their knowledge, their behaviors; she does interviews, observations, and uses methods like the laddering, the free listing, the card sorting, the task analysis and so on
- the raw results of the research are documented in a number of deliverables:
- the research is translated into the design of the product, producing wireframes or low fidelity prototypes, designing the macro and the micro information architecture, the interaction, the navigation; - a design system should be adopted and / or developed, identifying the components, the colors, the typography, the tone of voice - a high fidelity prototype applies the design system to the low fidelity prototipes - everything should be tested with the users, in different moments: competitive testing (to test the competitors' products), exploratory testing, confirmatory testing; prototypes should also be evaluated to verify the conformity to the standards and to the design system / style guides;This is UX design (different experts will describe it in slightly different ways, but the structure remains the same).
I'm obviously aware that this process would be a big effort for a side project. But it's very important to keep in mind that this is the right approach, and in the long run, the process will decrease the risk of failure.
[+] [-] navinsylvester|7 years ago|reply
The following is what i believe works for most time sensitive projects. It would be better to set a top level vision for the UX and give it to proven people to deliver. UI/UX is something that everyone in an organization can have an opinion very easily so your goal should be to satisfy end user and not everyone in the company. Take it as early as possible to beta testers and if your initial vision for UX is solid - it would take few iterations to get it correct.
[+] [-] evanmoran|7 years ago|reply
If you don't mind, could you explain what HCI is in your view as well? I think that's another discipline related to CS/UX/Design but is still quite distinct to those who understand it best.
[+] [-] pharaohgeek|7 years ago|reply
[+] [-] asien|7 years ago|reply
I never came up with a special talent for UI/UX. I remember I had a friend who was web developer he was insanely talented , could make a sexy landing page in just a few minutes.
For me this has always been impossible , I immediately start thinking about optimizations, legacy browser support , CI/CD etc... Typical issues of system driven person....
A few years ago I realized I wasn’t like him and it was « Okay ».
I found out I can’t do « many side projects » at once nor frequently.
Instead I only build one project at a time but I do it properly. I design things out in Photoshop or Adobe XD where I usually spend weeks before coding anything.
The goal is really to be working in pure V Cycle where you don’t start Prototype unless you are done with the design.
Been using this technique ever since and I haven’t been frustrated ever since. Would recommend to try it with any design software that you like to work with.
[+] [-] demarq|7 years ago|reply
Start by putting the technology aside, it only serves to bring your idea to life. Which bring us to the ideas...
Ideas are never 100% original. I challenge you to imagine an object of a shape and color not made from anything you've ever seen... it's impossible. What I'm saying is that you need to take inspiration from various sources. From this you'll be able to bring these elements together in a new way.
So I'd suggest looking at http://collectui.com/ and https://colorhunt.co/ to start.
Come up with a design in Illustrator/Designer and pretend HTML CSS REACT etc don't exist (ignore them).
Finally look at what you have created and realise you can bring that to life using literally any technology you like.
Mock out your components in HTML CSS.
create react/vue/angular components and port your previous HTML/CSS into these.
And Voila!
[+] [-] rkangel|7 years ago|reply
A good framework and set of components can help a lot though. I'm building a mobile app at the moment using flutter, and the material components in that make it so much more efficient to build nice looking things that work well. Animated transitions between screens for instance can be really fiddly, but flutter has support for some useful ones out of the box using 'hero' widgets.
[+] [-] leandot|7 years ago|reply
[+] [-] IronCoderXYZ|7 years ago|reply
- Draw out a design using Sketch, draw.io or any other similar tool.
- Find a color scheme, I typically google for "flat UI colors" since I like them most. Adobe color wheel is also a great tool for finding complementary / shades of colors: https://color.adobe.com/create/color-wheel/
- Then I start prototyping my ideas, typically in react, using a CSS-in-JS lib such as styled-components, this allows for quick iteration.
- I do research. For example, I look at how other websites or UI component libraries do things. Examples are material UI, ant design, semantic UI.
The most important thing is refinement. You start with a rough sketch, prototype in react or HTML and then start playing around with the CSS. Learning all the css attributes definitely helps. Don't try and learn them all from a list, but just google them as appropriate and you'll start picking them up. For example, you might think: "How do I center the children elements both vertically and horizontally on different screen sizes?". A quick google search will suggest to use display: flex, justify-content: center, and align-items: center.
[+] [-] jasim|7 years ago|reply
There are folks who're able to design in code (Basecamp style), folks who're only able to design in a drawing tool and does not know CSS at all (the Dribbble crowd), and the unicorns that I'm so jealous of who're able to play in both courts masterfully.
But knowing design doesn't have much to do with tools - HTML/CSS or Sketch. I've observed folks from all three categories, and my singular take-away was practice, practice, practice. Some people have an aesthetic bend that gives them an advantage, but most of us can build a basic understanding by being deeply interested in the craft and putting in the hours. Search for "how to be a designer", there is a rich array of resources. Pick a book like The Non-Designer's Design Book, an online course like refactoringui, and a DailyUI challenge. Start deliberate practice. Give it a few hundred hours.
[+] [-] mettamage|7 years ago|reply
https://bezier.method.ac/
Then buy a copy of Sketch and draw a couple of phone screens (by hand) [1, 2]. The idea is to do it by eye, so no cheating by using color pickers or measuring the pixels, do it by eye. Draw all the icons. In actual projects you can use icons but now you have the power to create your own.
Then do this one (the image)[3]. Now you should be on the level that you could draw any figure well enough as long as you have a reference image for it.
In my opinion regarding UI design there's no need to go further than this if it is purely for your own projects. The idea is to create a nice looking UI, not photo realistic images by hand ;)
[1]: https://www.invisionapp.com/inside-design/design-resources/d...
[2]: Sketch quick start: press A (for artboard) to plop down a screen. With R (rectangle) and O (oval) you can create simple figures. With V (vector) you can do the pen tool thingy that you've trained at bezier.method.ac. The rest should make sense on its own.
[3]: https://www.invisionapp.com/inside-design/design-systems-val...
[+] [-] jookyboi|7 years ago|reply
The best advice I can give in terms of managing UX:
0. Get Sketch (https://www.sketchapp.com) and use one of its UI kits (https://www.sketchappsources.com) to lay out your designs. While you should pay attention to visual details, you won't need to lay out every state since you won't be showing these to anyone else.
1. Build your project with one of the established frameworks (Material is pretty good). This will give you a sense of visual hierarchy and force you to think about why elements are placed where they are.
2. Introduce your own modifications and controls as needed. Even with a framework, you'll eventually come across a use-case that isn't readily handled.
3. Keep your modified framework in its own folder/repo. Continually update it as visual standards/technologies change. Doing this will cut down on the amount of re-work necessary when you're starting new projects.
[+] [-] xrd|7 years ago|reply
[+] [-] austincheney|7 years ago|reply
* Here is the site - https://prettydiff.com
* Config - https://github.com/prettydiff/prettydiff/blob/master/api/opt...
To automate this properly so that user performance is fast and maintenance is simple you don't need any frameworks or tooling. You just need a good plan and a proper organization of things.
About 80% of the user interactions are built from automation. There is some manual wiring that has to occur for various things where interactions are unique to a given option. The manual interaction stuff wasn't too bad when I wrote the code this past spring and it requires almost no maintenance. All the stuff that would be a pain the ass to keep up with is fully automated.
[+] [-] jtolmar|7 years ago|reply
* Your colors are too saturated, desaturate everything. (If you're using LCH, make 50 chroma your default for something that's "colorful.")
* Use more padding, more whitespace, and bigger fonts. Increase it until you're starting to get uncomfortable, then increase it just a little more past that.
* Remove everything you can remove, or if you can't bare to do that, relegate it to a dumpster page like an "about" section. Use the extra space this frees up for more whitespace.
* Whenever you think something needs more X, consider making everything else less X instead.
* If you're using LCH, you can do color theory by the numbers instead of eyeballing it. e.g. add 180 to the hue to do complimentary colors. This is not true of HSV.
* Establish a consistent visual hierarchy to group your content. Expect this to be the hardest part; even the best designers brute force this. The top of your hierarchy should frequently be the least emphasized part.
[+] [-] shortoncash|7 years ago|reply
For things that make money, I just hire a professional. There have been times where I have put a lot of personal time into improving a UI. What ends up happening is that that time ends up being a total waste of time because the UI/UX professionals are able to do the same work in a fraction of the time. It's almost never a waste of money, either.
[+] [-] vthallam|7 years ago|reply
Unless you have a friend who happens to be a front end engineer and who wants to work on side projects along with you, the best solution is to learn just enough to get by. Learn react or angular and learn how to customize existing free themes available out there.
[+] [-] franciscop|7 years ago|reply
It's been a great ride, and unfortunately impostor syndrome hits from time to time both on the front-end and the back-end (quite ironic). Though it's been fairly mild/easy to handle, I've had a lot of external validation through the years.
If you decide to learn it as your main learning focus (let's say, 15-20h/week), you could become fairly decent in 6 months-1 year. Then you can become quite good within 3-4 years. There are quite a few branches and ways to go about learning though, so if you want to learn I'd recommend searching and getting informed, but I deeply believe in the quantity above quality: https://blog.codinghorror.com/quantity-always-trumps-quality...
Alternatively, hire me :) https://francisco.io/ | https://picnicss.com/
[+] [-] danenania|7 years ago|reply
1 - Learn the basic principles (see d0m's comment).
2 - Borrow/copy like crazy from others who are better than you.
3 - Be brutally honest with yourself and know your limits. You don't need to be a brilliant designer to achieve that magical "good design" effect--you just need to get the fundamentals right and avoid mistakes. Until you develop some instincts, most of the ideas you have won't work, so you need to be willing to throw out what you've done and try again ad infinitum. If in doubt, take it out.
Last point: I think it's close to essential knowledge at this point for building viable software products. Like it or not, people judge by appearances, and good design is one of the best levers available to make people take what you're doing seriously. It's one of the top things that can take you from being perceived as a "hobby project" to being perceived as a "startup".
It's not easy to learn, but it's not really that hard either in the scheme of things, and it pays massive dividends. Even if you're using templates or paying someone else to do it, you still need to be able to distinguish the good from the bad if you want to avoid the (often subtle) mistakes that kill the perception of quality.
[+] [-] nathan_f77|7 years ago|reply
I really like starting with balsamiq for mockups, because I can figure out the functionality and don't have to think too much about the design. And then I like to use a UI framework with a set of pre-built components, and maybe a theme. Bootstrap is great for that, and you can get some great themes so that it doesn't look like a "bootstrap" site.
My favorite UI framework is Ant Design [1], because they have an amazing set of React components that are really nice to work with. I was blown away when I discovered Ant Design Pro [2] (which is free!). It's an "out-of-box UI solution for enterprise applications". Basically a fully featured dashboard built with Ant Design, including things like authentication pages, charts, etc. Everything you need for a side project, and it's easy to strip away all the stuff you don't want.
[1] https://ant.design
[2] https://pro.ant.design
[+] [-] tobinharris|7 years ago|reply
I used to be a back-end guy (I once co-authored a book on an ORM and just love middle tier and db shizzle). I had a huge appreciation for products that looked and felt great, but only had the back-end skills. I had a genuine desire to build skills in design so I could make better products.
If you want to take some short-cuts to build great looking stuff I'd do the following
- Build a mood board of stuff you think looks great. Set your own standards bar.
- Play around with Sketch or similar to learn how to get the look you like (this will make you think about UI design problems). This might take years but you have to start somewhere.
- Read "Design of Everyday Things" and "Don't Make Me Think" and a few other design classics. The principles stand strong.
- Get help from designers to bridge the gap between your skill level and where you want to be. When I started my company, I'd find designers who had a visual style I liked and paid them to help out.
[+] [-] garysieling|7 years ago|reply
Adobe XD is also a free prototyping tool - I would go through a tutorial or watch a few youtube videos of people working to get a feel for it.