How do I solve this?
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).
I would add knowledge about grids and negative spacing to the above list.
Why would someone only do something for money? Well perhaps they have time and money commitments that makes it hard to justify doing stuff that is not for money, unless it is super important for some other reason. So charity work might trump learning visual design, but visual design is also trumped by learning React because that looks hot on the CV.
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.
People that are good at it are like majestic unicorns to me.
Until then, if you are developing a compelling project that does something really useful, then people don't usually care too much what it looks like as long as it doesn't burn their eyeballs out of their sockets. It's true people pay for style, but you don't need style to get something out there and into the hands of people who can help you decide whether or not you now need to invest in style.
I don't have a background in design, I really struggle with color schemes, but I put in a lot of effort to design my software, and I think the resulting products look okay.
I've hired designers for a few jobs in the past. Their portfolios looked awesome, they were obviously good at their job, but when I received the work I commissioned, I was surprised how shoddy it was. They rushed it, and it sucked. Only after lots of complaining and multiple revisions did I get decent results.
It's not about being gifted. It's about putting in the work.
If you try putting a nice design on your product in an hour, you will fail. Take a week to research how other products solve design challenges, try a few approaches, show your work to people, revise it a couple of times, and you will arrive at a decent design, even if you don't think of yourself as a "gifted" designer.
* 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).
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.
You could start with the Wikipedia page to get a quick overview of what color theory really is: https://en.wikipedia.org/wiki/Color_theory
It is not the pseudo-scientific mumbo-jumbo strawman you're ranting against. Color theory makes no subjective judgements on what colors "mean" or should be used for, but instead focuses on the visual properties and perception of color.
The parent was talking about color harmony (color wheels) and color psychology. This are very much the things the Wikipedia article you linked is about.
Both are indeed pseudo-scientific mumbo-jumbo.
Color model theory is similar to music theory, in the sense that both theories may just be a codification of familiar patterns. That doesn't mean they're not useful.
Color harmony might well be just a codification of familiar patterns. Musical harmony on the other hand is very different. While it certainly has some parts that are rooted in familiarity, especially when it comes to consonance and dissonance of certain intervalls, most of it has a strong physical and physiological basis.
Musical harmony is not purely subjective and this is well studied. Color harmony is not well studied at all and if there is and serious basis - except for historical use - has yet to be been. That’s why I don’t like the word harmony in connection with colors. It just gives the wrong impression.
I don't know enough about the visual arts to know whether color harmony is a subset of color theory. Or if color harmony is even a thing.
To quote the OP: "How different colors mean different things (Branding-wise or for alerts/errors/warning)"
And, maybe I am wrong about this, but it seems like you've never even heard of color psychology since you seem to think that it's completely unrelated to color theory and that it's a strawman I cooked up out of nowhere. It's even linked in the related section on the wikipage for color theory https://en.wikipedia.org/wiki/Color_psychology
See: https://ping.apex.sh (black and white)
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
Don't look into Microsoft's design documentation though; even they can't decide what their design principles are. The only time they did, and stuck with it to the end, was Windows Phone.
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 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-...
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.
I know what you mean, but I now read "artistic nature" as making subjective/arbitrary decisions that for some unknown reason a lot of people favor.
Though by the way I read d0m's comment, it seems like there's a fair amount of objectivity in graphic design as well. Lots of logic: If you need to design something, it's because you have a goal and you need to make every decision in that design further take you to that goal. Gotta pick a color for something? Your goal means influencing people? What's your target audience? Pick a color that's statistically known to elicit the emotions in your target audience that lead you to your goal.
I believe that design should never be a creative process — when it is it means you are improvising — and that's simply disrespectful of the users. Well, you can have some sparks of creativeness (which usually is just an insight finally coming together from different datapoints now connected) but the process that brings you there is analytical, cynical, cold and methodical.
Explore the domain, document possibilities, group approaches and make comparisons.
To answer OP's question: the problem is usually time. If you spend 2 weeks developing a feature, why would you think 2 hours are enough to design it?
It would be like that Futurama episode where Fry writes a tv series episode script in hours and he's surprised that it lasts only 10 minutes.
The emotional result of perceiving the designed object, is still inside the realm of its function.
There are parts of design where you just have to follow logic, reasoning, good practices and have discipline.
It's either art or work, the medium (code or visuals) is not important.
Maybe it’s because I just stepped away from a harrowing 5 hour troubleshooting session (which I’ll be continuing on Monday), but I just can’t bring myself to agree with your comment.
You (and too many other people) make it sound like engineering is akin to following steps in a cookbook.
Ultimately, both code and aesthetics easy when building product. The hardest part is getting people to the product, signed up, onboarded, using, __and__ coming back for more...is very very hard.
- 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.
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?
Actually, Violet's grabbed my attention more. The dark backgrounds, the heavyweight bullet points, the bold letters... I guess my first reaction was that Violet's contained more information because it had a higher black-to-white ratio, and that's what caused me to favor it. Trixie's seemed too white (the black lines too thin) and so more difficult to read. I'm not sure what to take away from this. If Matthew's judgement is the more common one, maybe I'm a poor judge of what people would commonly think of as good graphic/typographic design.
Then again, maybe a large reason of why I favored one over the other is because I saw them as small images instead of printed pages. Maybe as printed pages, Trixie's would've read fine, and Violet's font would be too big and loud.
— John Warnock, co-founder of Adobe
This mentality died over a decade ago, especially given the rise of Apple and the mainstream awareness of Jobs as a design guru
It went through exactly the points you mention in good detail. And she also showed implementation of some of these ideas on the web.
* 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...)
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.
* 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!
After thirty years coding, I probably shouldn't admit this, but it's still a significant challenge to make these sorts of priority calls. This is even more true for side projects, where they're resource constrained by definition. It's easier to take risks and pay upfront costs when you have 40 hours a week to invest in a codebase than when it's only one or two hours a week.
Mainly because I find it efficient for me to use, I tend to do most of my side project work these days in Clojure. I think a bit part of why it makes sense for me to do that is that I'm carrying in a bunch of previous experience in Lisp style languages, and Clojure aligns fairly well with the way I think about building systems. It also aligns well because most of my professional experience is in the JVM, so there's a fair amount of carry over.
The reason I mention this is that I think it illustrates how subjective the notion of complexity can be. For me, in my context, it's simpler, but it's not hard to imagine it being absolutely the wrong choice for someone else.
There's also the problem of when it makes sense to pay certain costs. I have a little todo list application I've used to run my life for the last few years. My initial design idea was to keep it simple with exclusively server side rendering of the HTML. This focus on a simple approach has generally been a positive thing, but there are increasingly often features I'd like to add where the existing architecture doesn't work. The path forward is easy to describe - port to an SPA - but the effort involved is more than I have time for. My short term unwillingness to pay the cost of building an SPA four years ago is coming back to haunt me, just a little bit.
My solace there is that I probably wouldn't have actually had time to build the thing in the first place had I taken the time to make it an SPA. (And at least now I know that if I ever do make the port, it's likely to be something I actually use.)
So not an easy set of decisions to make, by any means.
> A driving factor for creating these has been to share my Vue.js knowledge with others.
This is another aspect of side projects worth considering. Sometimes they're built to solve a 'business problem' and sometimes they're built for pedagogical reasons (either self or others). That can have a dramatic impact on architectural choices, etc.
The latter is harder, so engineers tend to avoid it, often subconsciously.
Some of that depends on the audience for the app. For a technically sophisticated user base, having an interface that comes closer to the level of the underlying implementation can be quite powerful (and give a system a feeling of gestalt or wholeness that's quite satisfying).
That's one of the aspects of Emacs that I find the most valuable. A command is just a function in the underlying Lisp, etc.
But for less technical users, or even technical users in a 'off hours' or less technicial setting, this sort of UI can require an unduly high investment.
- 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
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.
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.
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.
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.
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!
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.
Why would you write anything that can't scale if you can avoid it? Whether or not you're looking to turn your pet project into a SAAS business is a moot point when you can get scalability for free with other approaches.
Getting something shipped matters more.
On an (albeit fairly simple) app that I'm building, my CSS file, using Tailwind, is 6.1kb gziped. I think that's pretty reasonable.
- 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.
Also, for color help, the Material Design Color Tool is a fantastic little site for helping develop color schemes quickly and visually. https://material.io/tools/color/
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 ;)
[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...
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.
* 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.
* 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.
This reminds me of my favorite design quote:
"Perfection is attained not when there is nothing more to add, but when there is nothing left to take away."
— Wind, Sand and Stars by Antoine de Saint-Exupéry, early French aviator and author of The Little Prince
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.
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.
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/
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 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.
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.
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.
* Space elements using flex-box. Use position attribute only when must.
* I've mostly ditched classes for Styled Components, but if you do use classes try to get most of the BEM-syntax and SCSS. Try to avoid id and element-wise selectors for styling.
* Use CSS preprocessor like SCSS. Makes your life easier. `&` especially.
* Use margins to position elements in relation to each other. Padding to maintain or inflate element's size. The difference between margin and padding isn't massive, but try to stay consistent in your styling.
* Use (as general advice) light background color with more distinctive primary colors, emulate your favourite sites' style to hone your visual skills.
* Don't overdo it even if the UI widget you found looks cool. For users the novelty will soon wear off and you'll be better off with something simpler and more functional.
* Also don't stress about styling, just maintain a distinct style that is simple and working and you'll be good until you can hire your own designer. Vast majority of start-ups with their fancy UIs are mostly just pretty balloons filled with air. Maybe it attracts some people, but most people (myself included) are happy with simpler layouts as long as they are easy to use. Sure if the site is indisputably ugly it can be jarring but you get the point :). Note that pretty visuals != good user experience.
In a nutshell, that feeling you get where you believe your projects look crap? It's because you're seeing the disconnect between what you can achieve now, and your taste that's informing what "great" is.
It's a bit of a double edged sword in that while you'll likely not be truly happy with a project anytime soon, that disconnect means you'll also be able to constantly strive as you recognise supposed flaws in what you've created.
In the end, all you can really do is just keep at it and over time, that gap will hopefully close as your skills allow you to create what your taste envisions.
That's the dream anyway, haha.
I used to use bootstrap, or download themes on themeforest. But since discovering Semantic, I've had a much easier time building front ends. It also serves as a guideline -- when I can't find something I want in Semantic, I have to ask myself "Is there a better way to do what I'm trying to do that _is_ in semantic?"
Also, with anything, it's a matter of putting time into the frontend. If you spent as much time on the frontend as you do on the backend, it would likely look better. It's easy to rapidly prototype a frontend just to make your idea work. Once it works, you move on.
Over time, you'll have a simple, usable app. And that is far preferable than a beautiful, shiny, but unusable app.
What I have come to realize though, is that if you keep at it, the aesthetic gains get bigger and better with each additional change and overall it doesn't take as long as initial progress rates would have to think.
I think the big thing is to value it as a user. Often if I make something for my own use, it's considered done when it works. To show someone else, it needs extra effort of value to others but not myself. When completed, of course I appreciate and am pleased by the outcome but would not have done it for myself. I think it's this difference between effort and perceived value that's demotivating. Practice reduces effort, but we have to also internalize the difference a nice UI makes.
Other than that, use a framework that has many components, or even better entire component set libraries available. Choosing a component set and tweaking a theme can do a whole lot in short order.
Second step - twitter bootstrap and admin templates for it are the little known secret of fast and cheap and good looking UI. Good templates are under $50, recently some nice ones started popping up on github under open source licenses.
One aspect that is hard for me and probably requires another half of the brain is making it “pretty” (or graphic design). Good news is there are tons of UI freebies, UI kits, free app templates shared on behance and dribble. Basically it’s pretty app designs created by people who don’t have skills to convert them into code. So they give that stuff away for free. Taking one of those goodies and using for your side project will make your project stand out without dropping a cent on professional designers. I always recommend freebies designs for MVP even when it’s more than a side project.
For the second, do you have some users or potential users (right needs, skills, etc.) nearby? Get them to use your software and watch them. Or use screen sharing to do it remotely, along with an audio link. Get them to talk through what they're doing. Watch to see the trouble spots, ways they approach using parts of the software that maybe don't match how you expect people to try to use it. Does the way your user interface is organized help or get in the way? Do the cool widgets you used make sense to people other than you?
Start this early, with the crappiest thing you can get up and running visually. Don't wait until you've invested huge amounts of effort in making things look just so. This may lead you to deeper changes but ones that might make the system a whole lot better.
Or, you could wait until you've put in so much effort and baked in so many decisions about how the system should work that you're not about to make any structural changes. Just put some lipstick on the pig.
For the layout / overall look pick a good off the shelf theme.
For UIs / micro interactions / content elements, see how other people have done it and copy them.
Other suggestions: - Team up with someone with some ui skills
- Use a css framework: https://github.com/troxler/awesome-css-frameworks
- Choose a color scheme and add some margin and padding to everything and stick to the scheme.
- React component libraries are becoming much more general purpose and easier to use. If you're up to sinking a few hours into it, try create-react-app (https://github.com/facebook/create-react-app) and then use a react component library like material ui (https://github.com/mui-org/material-ui)
It would be helpful to pickup a design tool. I've used figma and sketch, but I'm finding figma to be really helpful.
------------------------------------------------------------------
How I think of things is like this:
1. Either my entire day is dedicated to design
2. Or its dedicated to programming
------------------------------------------------------------------
I find it difficult to swap between design / programming frequently. One requires creativity / looking at lots of things for inspiration. The other requires a more logical mindset.
I would go further with this analogy, there's (4) main roles in webapp development
(1) UI/UX/Design
(2) Frontend Frameworking (React,HTML/CSS/JS/mocking things up, etc)
(3) Backend development (Firebase, nodeJS, etc)
(4) Database development / sysadmin / everything else
Try and only focus on one or two or those things everyday. You can skip (1) if you are emulating a website or building something with a heavy backend MVP. (3) and (4) can be mostly skipped if making a small project in firebase. (2) can be skipped if you use a CSS framework, etc.
Almost every possible control and behavior you need has been figured out.
On all my new projects I start with a commercial bootstrap wrapper. Wrapbootstrap has a lot of great ones for under $30. [1]
The templates come with everything from basic css to the newest wizbang stuff.
You can ramp on bootstrap layouts quickly because you can copy entire ui elements from the demo pages.
You can also build cascading templates pretty quickly using the examples that come with it since it is always the same layout largely.
I would not recommend trying to become a ui expert as top comment suggests, because that takes a long time. Instead, build with someone else’s great work in a bootstrap wrapper and learn as much as you need to move your project forward and no more.
I taught myself about color palettes, gradients, margins, and typography by carefully hitting inspect element on websites I love. You’ll get an idea of font sizes that make sense for headers, tables, written content and more. Inspect buttons to see how designers use shadows or changes to indicate function.
Once you start copying enough and read a book or two on design it will start making sense. Pay obsessive detail to how a payment flow or navigation reacts on a site you love when you do something wrong.
Less is more and start by building out simple forms that feel slick and intuitive. Copy the landing page of a website like Strava. Copy the landing page of a SaaS product you love. Copy the layout and typography of the Stripe documentation. You’ll eventually have enough tools to start making more informed decisions when you are not copying.
I've also heard some positive things about elm-ui (https://github.com/mdgriffith/elm-ui), which is on my todo list to investigate.
It's basically an Electron-based document manager with annotation and Anki flashcard support.
My background is cloud infrastructure so I'm really not an expert on UI / UX.
What I've been doing is that I use off the shelf UI toolkits that happen to look good aesthetically and have decent UI / UX already.
I also just try to do things that are 'standard' and not argue or have too much of my own opinion. I'm not a UI expert so I just do what the UI experts do...
Right now I'm using React and Reactstrap but Material UI also looks decent.
I also have a whole directory of screenshots I've been saving with really rich a and nice UIs that I can borrow ideas from.
Background colors. Layout designs, etc.
But UI/ UX is hard and it is very easy to get sucked down a vortex trying to get something to be exactly as you envisioned . And this drain on your mental energy can cause you to give up projects mid-way.
On the other hand, i always get a massive sense of progress when i'm able to interact with a feature through a UI.
I too despise(d) UI work like you when i spend a lot of time on things that i expect to be simple. The way i approach it now is to work with the mindset that the UI only has to be good enough. It does not have to look shiny and polished as long as it is able to deliver the value you are creating with your system.
Remember, design is problem solving. Art is expression.
Good design doesn't have to be pretty, and prettiness doesn't mean a design is good.
My assumption is your side project is for learning or enjoyment's sake. Learning design is a great way to spend that time. If the side project is purely for economic gain, instead spend your time refining your taste for design, learning how to articulate your taste, and recruiting designers who share a similar taste.
The great thing about practicing this as a developer is that you will eventually find a sweet spot where you can identify UI that is cheaper to build, but is also effective (vs. having to do pixel perfect designs where the last 10% doubles development time).
And, in the end, mostly copying other sites that follow similar functional requirements will get you a long way.
As for UX, if you have a spouse/partner/SO ask them to use your project and take their feedback seriously. Getting actual people to use what you've built is the fastest way to a decent UX. You have to set aside your ego and let the users dictate how they want their experience to be. It's non-trivial.
Spend that saved development effort on fixing bugs instead. A great app with a boring UI is better than a buggy app covered by a beautiful coat of paint.
For example let's say you're making a project that will help companies manage real time logging of data more efficiently.
Once a basic level of design competence is reached pretty much nobody who is looking for something like that cares too much how your site looks. You could make a simple landing page with a bootstrap theme in a few hours.
Develop an interest in design in general. It‘s a skill that grows with your level of immersion. It‘s helpful to have developed a taste before making design decisions, or even for deciding what to learn and who to follow.
You could start by reading about the history of design, especially where design started to emerge as its own thing from art in the early 1900s.
Knowing the history and political implications (man vs. machine etc.) is important, because many decisions, tastes and (especially typographic) choices of other designers may not make sense otherwise.
Here‘s a more general video you could watch now: https://www.youtube.com/watch?v=DBCa_jbxGfI
What‘s important to understand is that graphic design, architecture and product design did evolve at the same time, with similar underlying principles. It‘s all related.
Yes and no, it‘s more about a design mindset.
>And your thesis is a good understanding of architecture will help with design as well?
Sure. You don‘t need to know how to build a house though. It‘s more about the motivations of the designers and the practicality and purpose of the designs, how designers think.
You can see similar debates between architecture and typography when it comes to ornamentation, the usefulness and practicality of it, and the appeal to conservative, progressive or even post modern audiences.
That‘s also why it‘s similar to politics, the‘re fanatics on either side. If you understand this it will be easier to find a balance in your style that is right for the audience you design for.
To develop a deeper understanding and taste, I would recommend "Design Basics" by Lauer & Pentak. I’ve studied and taught design from it and think it is a great introduction to the fundamentals. The latest edition tends to be overpriced as a general rule. I would go for one of the older editions. Personally, I don’t think the content improved any after the 5th ed (which is excellent). Immersing yourself in that kind of content can give you deeper understanding of why specific suggestions from folks like RefactoringUI work as well as they do and develop sensitivity in perception.
Focus on a problem you want to solve. Make your product useful. Make sure your product works and provides a value for a user.
If you (when you) succeed in above, then you can address UX/UI based on feedback and usage findings you will already have.
UX is overrated, at least in the beginning of creating a product. That's why the web is full of crappy products and derivated ideas which just look nice.
Just my 2 cents as a product designer.
(peace)
UX/UI is HARD, it takes many iterations to get it right. So, don't get disheartened if the first several dozen attempts fall flat. Just keep on.
It' more efficient to do the visual design on paper, or some mockup tool. Forget whatever framework they're peddling at the moment, technology choice comes after you've decided what you're going to do.
I’m copying images etc and buttons don’t work because it is the layouts that I’m trying to get right.
I’ve learnt so much doing this that it has really helped.
Reading some css tutorials and learning css is a world away from having to find a way to get an element to appear in a very specific place.
If a side project turns out good enough that I think it could be a real product, I expect I will try to find a partner.
Also themeforest.net is great too, pharaohgeek mentioned that already, but that is also a great starting point as good themes look more like bootstrap documentation to give you a huge head start versus from scratch.
1. As other comments have mentioned - if you are willing to pay, a good designer will go a long way.
2. Use a common component library with a custom theme so it is good code but not 100% the same as elsewhere
3. Keep lots of whitespace between everything
4. Keep it simple - good UX is about so much more than UI and feature creep is so often the enemy of good UX
There is a lot more theory and practices than I will ever understand. But if you are not an expert, just ask yourself if you would want to use it. Not as a developer, but some random user.
Increasingly the "user experience" transcends just the web app, and involves well timed SMS messages and notifications.
Once the essential UI is defined, I use Balsamiq to iterate on a design, then over-communicate specifications for an Upwork Freelancer to bid on.
Obviously, this works only if you don't need any custom elements, but I'm not a designer, so I just usually use what's available.
For UX, read about UX research and show your work to potential users, make them talk constantly and just listen, see them struggle. It's priceless.
If you have time, go through the versions of my single page app (single file, actually):
I try to resolve the shortfall using Themes on bootstrap and then freelancers to resolve ad-hoc issues.
Palette generators, so colors will look good.
Simple interactions, to kill two birds with a stone: ease of development, minimize UX mistakes.
Find me at www.mathlete.com
1. Cluttering the website with too much data: It seems like a dire need for founders to put as much data as possible to explain their product better. But too much data can backfire confusing the customer in understanding what your product is all about. This makes the website look boring, uninteresting & confusing. In such cases using different font weight, size, colors, relevant icons or relevant graphics makes the landing page more meaningful & engaging for the visitor.
2. Using too many colors: Using many colors randomly on your landing page does not make it look more fancier. Colors are used to differentiate the contents of the website. They facilitate the customer in quick understanding of what the color denotes. Ideally, the easiest way to set up a color palette for your landing page is to use colors from your logo & add complimentary colors to it. For each of these colors, have a lighter & darker tone available which would help you set up a complete color palette for your landing page. It’s best to start creating your landing page once you have set up your color palette.
3. Footer is important: Many founders did not include a footer on their website. If included, it wasn’t used effectively displaying the relevant navigation to your website. Ideally, you should have a footer which should possibly have all the links from the navbar, and other links which couldn’t be put in the navbar. You should also have social links, even though somebody will not click it but having them builds trust in your website. You should also put some contact details; either email or phone number which adds to the credibility of your website. You can repeat the logo in the footer. This is also an important factor for brand recall. You can convert the logo into a single color and put it in your footer.
4. Missing call to actions: This is one of the most critical errors that founders missed for their landing page; i.e. not having a call to action near the end of the landing page (just before your footer). This is the point where the customer has been through your complete product and understands what you are all about. It’s the best place where the customer is most likely to buy your product/services. Ideally, all pages redirected from the home page to other important pages must have call to actions too.
5. Unaligned website contents The content of the website is set to full width and not aligned as per the container. The flow gets lost and the whole page becomes confusing and irritating for the visitor. This will lead to the visitor bouncing off much quicker.
6. Description consistency & balance: Many products had multiple features to pitch their customers. But each feature had different description lengths between 1-5 lines. This creates an imbalance in the landing page which makes it look fuzzy. All description length must be equal and ideally 2 lines or a maximum of 3 lines.
7. Typography: Many landing pages had multiple fonts used on the website. Ideally, you should be using 1 or a maximum of 2 font families for your website. Avoid any fancy font for a blob of content. It becomes unreadable and hence more likely for a visitor to bounce off. Most creators use a default line spacing. Adding slightly more line spacing to your text would make it more readable and interesting.
We would be happy to have a look at your side project and share constructive feedback. http://draftss.com/feedback.html
Unless you feel tackling three very, very different problems at once I recommend you treat them separately.
* Functional Design: Think of the right things to do at the right point in your app in a way that engages and works for the user
* Aesthetic Design: Pick the right colors, sizes, margins, fonts, icons to support the functional design aspect (keep it simple, skip illustrations)
* Web Design: Get it to CSS/HTML/JS
It is very simple to get a random aesthetically pleasing thing going (there's a ton of theme resources out there) but for obvious reasons those do not include any consideration to your projects functional design needs, which then trickles down to the lack of strong aesthetic elements and an app identity.
My recommendation depends on the type of person you are and what you are looking for. Do you wanna do self-reliant and do everything by yourself? Think of it as another never ending journey (just like the coding one) and enjoy the ride.
I think tailwindcss is one of the best tools to guide you towards making a lot of right decisions quickly when it comes to aesthetic and web design. Starting keeping bookmarks of whenever you stumble across a page and think "this feels/looks good". Review whenever you wanna build something. Make it easier on you: Skip graphic heavy stuff, pay extra attention that work through great typography, borders, use of colors.
Functional design, well, is super fucking hard and I don't know of any great online resources that teach it on a high level (anyone?). It depends so heavily on the individual problem you are trying to solve and has so much to do with critical thinking, understanding the entire problem space (including user motivation, where they might struggle) and intuition.
To make this part not completely overwhelming definitely work on a problem that you personally have (or at least can heavily relate to), think about that problem as much as you can and figure the simplest possible steps to get you there.
The alternative route would be to work on finding a co-creator, someone who fills in the gaps. Since we are talking about side projects you can absolutely live a little dangerous here and start connecting with people over indie hackers, hacker news or whatever but if you know someone you have worked with before, and feel like you might enjoy working with on a side project go to them first.
good luck :)
0. Use a css framework like Bootstrap or Bulma, it's not difficult to put together a website/webapp with a bit of CSS skills (you don't need to know a lot of CSS to create a good experience)
1. Team up with the UI/UX designer who you've worked in past and offer them your backend expertise for their project.
Good ol barter has saved my ass multiple times by now.
2. If you don't want to get someone from your workplace, you can go on upwork etc...and hire a freelancer, it's a paid option.
I agree containers are confusing but honestly making a custom web app look good on all resolutions/aspect ratios is complicated in my opinion.
However, if you know how to work with Bootstrap, I don't see a reason to learn something else for side projects, if you want to minimize the effort you put into front end stuff. It might not be ideal, but it's good enough imo.
That said, the Bootstrap 4 defaults are much more modern looking than Bootstrap 3's.
Note the criterion here is speed, not modernity or aesthetics.
Edit: by speed, I mean speed of development, or ease of development.
I've found that bootstrap remains the best option to create a reasonably responsive, simple layout that is still quite usable on mobile as much as on the desktop, with no more than an hours' worth of work. And you don't even need to know css really.
I've used vanilla CSS and HTML and even after hours of amateur effort the site always looks like it came from the 90s. I don't have the time to worry about what font family I want to use, is that too much to ask?
just pick the library with the largest component set in whatever frontend stack you use