Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you manage UI/UX for your side projects?
402 points by break_the_bank on Dec 7, 2018 | hide | past | favorite | 199 comments
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.

How do I solve this?

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.

Made the bullet list readable on mobile:

* 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).

This is so ironic with a comment about UI & UX.

Is the end user (commenter) responsible for UX or the HN web designer. In this case I'd argue both are.

I didn’t want to be the one mentioning it ;)

It's more readable on desktop as well. Long lines in HN's code blocks render with horizontal scrollbars - using them to quote paragraphs is downright obnoxious.

Worse is that the horizontal scrollbars don't render (at least for me) unless I start scrolling the box, so it looked like there was just some missing text.

HN really needs to copy markdown for lists starting with * or 1,2,3,4 etc

> 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.

For design you have to have an artistic nature.

Probably on the same lines of the sibling comments, but here's my 2 cents. (I'm the design lead at software company, strong fronted dev background)

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.

But design is also incorporates an aesthetic which I imagine may not fit in as nicely to the "form follows function" principal as we might think.

Actually once you know all the details of how form affects the fruition of function, then even aesthetics are just a matter of incapsulating that knowledge into the product.

The emotional result of perceiving the designed object, is still inside the realm of its function.

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.

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.

> 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.

Yeah, I get it, even art has to follow some ground rules to begin with, but do we know what exactly is it that makes Beethoven’s “Fur Elise” such a great composition?

Music is a very different domain than visual design and we have heuristics for both that, if followed, will keep a musician or designer from composing/designing something demonstrably 'bad'. Will it be brilliant? Likely not, but "not bad" is not a bad goal to aim for.

It's helpful to deconflate art and design. Design uses artistic tools in the service of clearly defined and objective goals. It is a learned skill.

There are parts of engineering that require an artistic nature.

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.

Yes and no. Design (as I think you're using it) is not UI / UX.

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.

Good UI is also logical. I'm always thinking about what's more ergonomic, what's intuitive, etc.

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.

I would recommend checking out Refactoring UI, there is a YouTube channel, blog posts, and a book coming out next Tuesday. Their tips and samples from the book have already made a huge impact on my designs.

One other thing to add is that you can't make a good design without content. Unless you have all of your content ready to visually position/style, don't bother designing yet. I used to try to make the visual layout first without really thinking about content, and it was always a struggle.

Sorry for the plug, but since others are asking for an introductory resource, I wrote a short course on UI Design myself not too long ago. They are just 17 short tutorials: https://www.commonlounge.com/discussion/d5bae026ef6e4f949e63...

Link hangs on 'LOADING..."

Can you point me to this specific course? I am interested.

Which course did you take?

Can I have a source for the crash course? Asking for a friend!

I need to take this course

I wonder, is this a positive externality? I spend my free time doing this course but do I get paid more? Or do I just deliver more value to my employer at the same price?

Yes and no. Why do you care?

Why do I care about getting more money? Well...

You're considering learning one of the most important fields that will probably impact the way you think, reason about and look at the world. And you're thinking about money.

This is kind of my point - we would like developers to learn this kind of stuff but there is no financial incentive even if it is good for their employers. There are a lot of facets to our work that are like this, for example some soft skills would be in this bucket, except for the soft skills linked to becoming a 'team leader'.

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.

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.

Also, learn about gestalt principles. For example: https://www.howdesign.com/resources-education/online-design-...

> 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?

"Good typography is something everyone sees but no one notices."

— John Warnock, co-founder of Adobe

Matthew Butterick says it better than I ever could: https://practicaltypography.com/why-does-typography-matter.h...

> Whose ré­sumé got your at­ten­tion—Vi­o­let’s (the first one) or Trixie’s (the sec­ond)? [...] I’m guess­ing you picked Trixie’s.

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.

> If you truly preferred Violet’s résumé to Trixie’s, you didn’t fail some typographic litmus test. The point is the same—whatever preference you had, it was based on typography, not substance. (Though after you read more of this book, come back and see if you still prefer Violet’s résumé.)

Well I'm not saying to become a typography expert, but it's important to understand how font types relate to each other and how to increase clarity based on the context. For instance, print vs slides vs web page, or a little bit of content vs some heavy content could probably be improved with different fonts. Also, even if people don't notice it, the typeface/font is part of the branding and it creates different experiences. I.e. it makes something look more friendly or serious.

It matters because of Comic Sans. :)

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.

As an engineer, I think design is so goddamn hard.

People that are good at it are like majestic unicorns to me.

Agreed. Beyond some trivial basics all these "theories" of how to use style are really a thrashing excuse for the fact that people who are awesome at this really do have a gift, and if you want your product to look great than at some point you have to hire them.

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.

Good design is not the result of "having a gift", good design is the result of hard work.

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.

> A lot of engineers have the mentality of "engineering is hard, but design is just whatever some color matching and styling".

This mentality died over a decade ago, especially given the rise of Apple and the mainstream awareness of Jobs as a design guru

> 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

I'd add Apple's Human Interface Guideline document and annual WWDC sessions on user interfaces. Even if you don't use a Mac or iOS device, or even if you hate Apple, taking the time to understand why they think their user interfaces are the best on the planet goes a long way to being able to understand why other companies also think their user interfaces are the best on the planet. The ideal result isn't a happy medium, though; it's whatever suits each platform best, something you only understand when you know what each platform's designers are going for.

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.

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.

- Don't be distracted by all the blog posts.

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.

Yeah, a bit ironic but don't let that stop you from reading and understanding the content.

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.

I recently went through Sarah Drasner's workshop "Design for developers" https://frontendmasters.com/workshops/design-for-devs/

It went through exactly the points you mention in good detail. And she also showed implementation of some of these ideas on the web.

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.

Is there a book you would suggest for reading on these topics? I prefer it over a website for offline reading.

Is there a tutorial, course, or book that covers those four points specifically you recommend?

This is an amazing resource! thanks for sharing

Steven Krug has a good book as well.

> Basic of color theory

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.

That is not color theory, at all.

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.

Color theory is a wide subject. The context it was used in this discussion was for design and the influence of colors on the end user for things like UX, branding, etc. Yes, color theory also includes important and technical things like color spaces and human perception but that's not what we were discussing here.

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

> 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.

I'm also doubtful about color psychology, but color model theory (including color wheels) has some real substance. Most web sites from the late 1990s are today recognized as ugly because the color choices were awful (perhaps because they were trying to be compatible with graphics cards that only allowed 8 bits per pixel.) Web sites with colors that fit a recognized color model appeal to a lot more people.

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 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.

They said music theory, not music harmony. Music harmony is a subset of music theory and music theory is a codification of familiar patterns. Those patterns likely formed because of their strong physical/physiological effects.

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.

You don't need knowledge of colors to create a nice UI/UX.

See: https://ping.apex.sh (black and white)

I stick with a few basic guidelines:

* 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.

* https://github.com/ryanrodemoyer/ParlayTools - available @ https://d3itp7yns2kqcy.cloudfront.net

* https://github.com/ryanrodemoyer/AccrualCalculator available @ https://accrual-calculator-prod.herokuapp.com

Good luck!

> 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.

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.

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.

> UI reflects internal code structure instead of just doing what a user would want to see.

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.

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.

This a really excellent response. Thank you.

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.

I will sometimes buy themes before I even have a project in mind. For $20-60 you can't beat something that just works and now you just need to inject your code into it.

But if you get to charge someone it is not so cheap...

I second this - but just be aware of the regular license vs. extended license requirement (i.e $20 vs $800 for example). Although if you get the point where you are charging for a product and need an extended license - that may not be a high price to pay for a quality theme you would probably spend 10-100 fold paying someone to create something similar.

>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.

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!

> 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.

Frameworks like these are terrible for your document size and page load performance once your project scales.

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.

It seems verbose yes, but since everything gets minified + gzipped anyway and there is no additional js it is actually quite light in the end. If the parent has difficulties with UX/UI, it might help to look at it from a different angle.

I mean, with something like PurifyCSS or some other 'css tree shaker', something like this is perfect.

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.

Because the overwhelming majority of side projects will never need to scale.

Getting something shipped matters more.

How? This is a tiny functional CSS library.

Here is what I typically do:

- 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.

To add to this, another great design tool is Figma – it's browser based, but just as capable as Sketch. Although working in the browser often feels like a toy, the bonus is that it's cross-platform unlike Sketch.

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/

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.

For getting some UI drawing skills go to:


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...

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.

* 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.

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.

> Remove everything you can remove

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

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...

Alternatively, hire me :) https://francisco.io/ | https://picnicss.com/

I think it can be distilled to three key things:

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.

[1] https://ant.design

[2] https://pro.ant.design

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.

I could write a short tutorial here how to do basic styling but I don't know will you gain anything from it. Having done HTML/CSS/SCSS in between my full-stack JS/TS work, instead I'll just list some of the things that I've learned from doing web UI/UX. Maybe you'll get some insight from it, people have mentioned other great tools like Sketch which are great but these are some practical tips.

* 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.

One thing I always like to go back to is Ira Glass's video on taste: https://www.youtube.com/watch?v=X2wLP0izeJE

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 highly recommend using semantic-ui, which has a fantastic react port https://react.semantic-ui.com/

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.

Came to say this. Semantic UI react has almost everything you require to build good looking UI for non designers.

Keep the UI simple. Find a free/cheap template, throw it up, and add your code. But then... use the app. Be aware of when you are clicking multiple times to finish a task, when you have a small hesitation to parse your own icons and menus, when you jump all over the app to get something done, etc. Those are small inefficiencies to you, but broken UX to someone else. Over time, you'll have your own annoyances with the app. Fix those. And when you get real users giving you nitpicky complaints about the UX, treat them as serious breakages of your app.

Over time, you'll have a simple, usable app. And that is far preferable than a beautiful, shiny, but unusable app.

I know a bunch of UI/UX folk, and I tend to just ping them if I have anything to design. Works quite well - many people will do a lot of short term work in exchange for pay.

I have gone through the same thing on many of my projects. Some projects however do get to a better level of done on the UI. My greatest source of discouragement is the expected effort it will take to evolve the UI to a desired state. This comes about because making front end changes seem to take a long time just to look up some CSS combination etc, and it still looks very basic.

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.

IMO you need to start loving UI/UX to get anywhere. It’s actually interesting and with modern frameworks is not too hard for a decent programmer to pick up. Getting out of your comfort zone and learning new paradigms, solving new class of coding challenges etc will also make you a better backend engineer. Think of it as a good investment.

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.

And also google “best google webfont pairings” pick one, apply it to your bootstrap site with only 10 lines of CSS and voila the page suddenly feels fresh and cool

First decide if you just want it to look nice, or if you want it to work nice. For the first there are already lots of suggestions here.

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.

Disclaimer: I'm a frontend/fullstack dev. One of the methods I use is browsing other sites and taking inspiration. You can even inspect their elements if you'd like to see how they the style (don't copy paste!).

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)

I've been exploring the world of UI/UX recently, and I enjoy it.

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.

You should not be inventing ui/ux for an early web application at this point.

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.

[1] http://wrapbootstrap.com/preview/WB0N89JMK

Use a service like http://draftss.com/ or http://manypixels.co/ They provide a good value for the price. Alternatively, hire a designer accordingly to your budget

Cop, copy, copy.

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'm building a mobile app using flutter, which has so far been an excellent experience. They've announced development of a web version of it - hummingbird (https://medium.com/flutter-io/hummingbird-building-flutter-f...) which I'll be keeping a close eye on. Not only is it a fundamentally productive toolkit to use, but sharing both business and UI code between all frontends (desktop, mobile and web) would be wonderful.

I've also heard some positive things about elm-ui (https://github.com/mdgriffith/elm-ui), which is on my todo list to investigate.

My side project launched on HN about 4-5 weeks ago:


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.

Jeremy's Web design in 4 minutes is a crash course on how to build up the different elements that go about in web design : https://jgthms.com/web-design-in-4-minutes/

A lot of good suggestions here already. I agree with another comment that UI/ UX is very important, especially if your project is intended to be used by the general public.

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.

Visit a site like http://behance.net and find layouts that inspire you. Spend part of your side project time replicating those styles and understanding/learning why the design decisions were made for that project.

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.

Frameworks like tachyons and bulma will give you the tools to create elements that don't look terrible, but imo UX just takes practice. (I'm using tachyons on my side project http://oozesaga.com (the UX is still pretty bad))

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.

for UI, HTML5 Boilerplate will get you pretty far when it comes to organizing markup. Then you can start with something like Bootstrap and then build a theme when you're ready. There's some truly impressive pre-built bootstrap themes/templates out there too but they take a lot of work to integrate into your project.

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.

I know this question is about web apps where there is little in the way of “standard,” but if it’s a desktop or mobile app, please, please use standard, system provided controls and menus, the generic system font, and well-known button icons. Don’t try to invent your own. Your users will thank you because they will know what everything does without having to figure it out. Plus, on many platforms, straying off the path of standard controls can lead to 10x or 100x the code. Just don’t do it.

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.

Is it a project where one of the most important aspects of how it works will be the design, if so maybe you can trade with a designer or even pay one for some help. If it isn't the most important thing try to find a theme or example in a common framework that will be passable.

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.

Check out: https://refactoringui.com from Adam Wathan and Steve Schoger. Comes out Tuesday (12/11) according to their podcast.

>How do I solve this?

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.

Any resources you can recommend for learning?

RefactoringUI series already mentioned is great for specific tactical tricks that are immediately applicable.

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.

Thank you. I appreciate the recommendations. Where was RefactoringUI series already mentioned?

Design Literacy by Steven Heller is a good comprehensive book about graphic design.

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.

Thank you so much! The video you linked to is about architecture correct? And your thesis is a good understanding of architecture will help with design as well?

>The video you linked to is about architecture correct?

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.

https://elements.envato.com/ has a flat subscription with lot of resources you can use in commercial projects.

Don't bother with UX/UI at the beginning. It's wasting your time and resources.

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.


Observe what you like and dislike about the existing interfaces you use. Try to emulate the former and avoid the latter.

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.

Use default theme of some tookit (e.g Bulma or similar) and don’t change one bit anywhere. As soon as I even think I can change a margin somewhere it all goes to hell.

This is my problem as well, I’ve started to take web sites I like the look of (like mobile twitter) and first drawing them by hand and then using plain html and css try and copy them pixel for pixel.

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.

I shamelessly copy. I have a lot of respect for the UX and design people I work with, and I know those skills take hard work to develop even for people with talent. I know I'm never going to finish a side project if I force myself to acquire those skills myself before I do anything, so I copy existing designs that look good to me.

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.

Adobe XD is part of their creative cloud offering and they publish themes and videos about the design process. It is really easy to mockup a real looking web page in XD, then use a favorite CSS framework to create it.

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.

You are right to be concerned - so many side projects don't gain traction due to simple UI issues putting users off.

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

I was never formally educated in that field but I just try to make something I would want to use. Bragging: I've been complimented by a Xerox exec "this looks better than our software"

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.

Since we have a lot of customers like you, we have been investing more and more in educational content about UX for non-designers. Check it out if you're interested [1]. It's all fairly new so we'd love feedback on it.

[1] https://balsamiq.com/learn/

I would start with diagraming the overall process/workflow the app is enabling.

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.

I try to use frameworks which contain building blocks, so I can just use existing functional elements (like Alert in Bootstrap, etc.) without having to come up with my own css rules.

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.

I think buying themes or designs from marketplaces like themeforest works best for me, I then improve on those things by taking inspiration from similar apps or companies on how they are displaying certain information, navigation flows and try to mimic as much as possible. This gives great results.

UX can be a product feature. Or can overlap them. Develop some fascination with what improves user experience and you will naturally develop the motivation to work on it. Separate it a bit from "just" design/UI in your mind, and think about the user's needs and their psychology.

I would use a "Component" front end framework like Material-UI or Blueprint, that way you can avoid spending your time on CSS/JS issues and spend most of your time building the application. The downside is that your application will look like the component framework you select.

Read Jeff Gothelf's Lean UX. It illustrates product mindset, shows the survey and analysis work that goes into creating a new product and where creating custom software fits into the whole process. Given this reference by a UX designer. Great read.

For UI problems, grab or buy a UI toolkit, it's better than you trying to write one from scratch.

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.

What I do --- Iterate.

If you have time, go through the versions of my single page app (single file, actually):


I am in the same boat. I try to use the same basic look and feel and interface everywhere. I just use whatever formatting the framework comes with and then I might ask someone else to step in and give me css and logos etc later.

Small addition to what everyone said - pick nice icons, a page with just text feels empty. A nice set of icons can change that. Many sites are made of just text and icons, and in such situation icons bear a huge importance.

If it's a small project I'll use bootstrap which then I customize. For anything larger I just pay a web designer. He/she might also use bootstrap but their customization techniques far exceed my capabilities.

Do basic stuff and tell everybody you're keeping it simple. See https://pinboard.in/. At least programmers like it.

Not affiliated, but if you’re using rails, rapidrailsthemes is quite nice.

Decide if you want to be a designer. If you don't, then hire one and make sure you pay them as well as you'd want to be paid. If you do, then do your equivalent of going to school for it.

I face the same problem and honestly, design is hard. Even basic design skills are a lot of effort.

I try to resolve the shortfall using Themes on bootstrap and then freelancers to resolve ad-hoc issues.

Bootstrap, so I have a consistent style. Any other equivalent library would do.

Palette generators, so colors will look good.

Simple interactions, to kill two birds with a stone: ease of development, minimize UX mistakes.

For side projects, I always try and get as far as I can with a CSS UI framework, then ask friends for help. It's much easier to brief people if you have a woring prototype.

Material Design standardizes visuals and mini-workflows that you can stitch together. The spec is easy to approach and every major JS framework has an implementation.

https://canvas.hubspot.com/ My best resource for reading about UI/UX.

I'm very experienced at UI/UX and suck at programming, so I'm happy to help you out. (I might need your help too one day!)

Find me at www.mathlete.com

I hire freelancers, If it's a small project I hire freelancers from Fiverr and for important things I hire from Upwork.

Read Jeff Gothelf's Lean UX. Shows a product mindset and how to use that mindset to create great software products.

Bootstrap. I just went for the most popular because i m more likely to find googable answers to my needs.

Sans serif font, dark gray text on light gray background, massive padding and you are in.

if it's just some fun pet project ill copy a color scheme from something i like. if it's for a company i'll higher a designer, who generally copies a color scheme from something he/she likes. :)

Look at CSS of websites that you like and copy aspects you like?

This is one of the major problems of founders who fail to realize that UI/UX is a critical aspect in defining the product's utility even at an initial phase. We worked out on providing feedback to founders who found difficulty in optimizing their UI/UX resulting in an improvement of conversion rate. I am a co-founder at http://draftss.com and we have shortlisted few important mistakes that founders did on their side projects that could make a significant difference in the purchase decision by prospective customers:

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

Something that I feel a lot of coders grapple with is that these 3 tasks are highly disconnected from each other. It is absolutely common to have someone who is incredibly proficient with CSS (maybe more and more so in tandem with some front-end JS skills) to have absolutely no concept of how to come up with a strong design in any reproducible, timely fashion.

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 :)

I've multiple solutions:

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.

Bootstrap is so antiquated. It is also far from easy, and even if you learn a lot about bootstrap is will not make your project suddenly look good. Not to mention the container system is one of the most confusing things I have ever seen, but maybe that is just me.

What would you recommend in its place? I’ve been using bootstrap for any web side projects of mine mostly for its ability to flex and handle multiple devices sizes and also because its defaults look passable out of the box.

I agree containers are confusing but honestly making a custom web app look good on all resolutions/aspect ratios is complicated in my opinion.

Not OP, but I recommend using plain css. With the grid layout and flexbox it has become pretty easy to create something decent and learning flexbox and grid isn't hard. Grid works basically the same as Bootstrap: split a page in parts and tell each element how many parts they can use. But with gird you don't to split your page in 12 part, but can choose for yourself how many you want. Flexbox is rid, but for things you want to arrange 1d instead of 2d.

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.

Plain CSS is missing the main feature of these libs, which is simple-as-crud components that match visually and help you build out pages that have the UI patterns users expect.

I second using vanilla css. Vanilla css is a lot easier to understand than bootstrap imo. Vanilla css + HTML5 is good enough for pretty much any web page.

Yup. Learning basic web platform technologies is the best investment too. They're not going away, ever. (Comparend to the currently fancy libraries/frameworks). And it will help you understand all the things built on top of the web platform.

At most use the Bootstrap grid system. Roll your own component styles, particularly if you're trying to sell whatever you're building as a product. Otherwise, your project will lack identity. I'm more sensitive to it than most because of my background, but if I see an app using Bootstrap defaults, it negatively affects my opinion.

That said, the Bootstrap 4 defaults are much more modern looking than Bootstrap 3's.

Try Tachyons. I’m playing with it for a new project and liking it a lot so far.

I like to start with Skeleton CSS or similar, strip out all the column stuff, and just rely on grid and flexbox to build the layout.

Bulma is great for starting :)

Bootstrapping a proof of concept, or a very early version of an app, definitely is still very much relevant. Bootstrap aids in this. And I think it is widely accepted that if you have an app that you'll eventually scale it needs to be refactored out. But for that initial POC, bootstrap away!

I disagree. Bootstrap is not that hard and the template wrappers make ui ux much easier for a backend person.

You can use Boostrap's "grid only" option. Which gives you a FlexBox based 12-column grid, and none of the styling. I think it's a pretty good option for people who want custom styling, but don't want to reinvent the wheel for a grid.

What would you recommend instead?

Note the criterion here is speed, not modernity or aesthetics.

Edit: by speed, I mean speed of development, or ease of development.

Bulma is easy to understand and very fast to start using.

Speed? Do it yourself, you only add what you need, no need to bloat the styles with anything you're not going to use.

I've been designing barely acceptable web UIs for my side projects for 17 years now and I think this is poor advice.

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?

use a widget library. my last startup used


just pick the library with the largest component set in whatever frontend stack you use

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact