I am constantly developing little web applications and became very good in a basic Full Stack environment with JavaScript and some database. Good enough to serve to a few hundred customers, fix bugs etc. I am a full time JavaScript developer, and what I am lacking are the skills for a good enough design to present my apps to a broader audience or investors. Also, UX/Design plays a huge role in if customers pay for a service or not (in my opinion).<p>There are many books and courses out there, and I am kind of lost.<p>So, does anybody have tips of how to get started to polish web applications to a good enough design to go public?
If you mean the visual "look", I would just buy a template or engage a designer (even 99 designs). This is for graphic design in the sense of layout, color, fonts, etc.<p>If you mean UX in the sense of "how it works", learn about user testing (just watch people use your app) -- that's the biggest bang for the buck, IMO. Krug's "Don't make me think" is a good start.<p>If you mean UX in the broad sense of "your user's life is improved by using your app" -- this is more of a product design thing -- my go-to recommendation is learning about Jobs-to-be-Done theory. Start here: <a href="http://jobstobedone.org/radio/the-mattress-interview-part-one/" rel="nofollow">http://jobstobedone.org/radio/the-mattress-interview-part-on...</a> and then look around that site. Learn about "job stories": <a href="https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27#.mpvd4nqcr" rel="nofollow">https://medium.com/the-job-to-be-done/replacing-the-user-sto...</a>
Who are your customers? Businesses? End Users? And how much of an improvement in sales would you expect? 10x?<p>I'm pretty bad at UI too, and I'm building a project with a partner, which we hope will become a startup, so we hired some freelancers to help with the UI and UX part :) . If you expect a 10x improvement in sales, maybe it's worth it :)<p>So far it's not as expensive as we feared, but we haven't launched yet.<p>There's also another thread on Ask HN about it. It basically says to copy and to practice:<p><a href="https://news.ycombinator.com/item?id=10948099" rel="nofollow">https://news.ycombinator.com/item?id=10948099</a>
tldr: iterate, iterate, iterate.<p>Learning how to generate and test design hypotheses both with and without users is really important. I too am programmer and design did not come naturally at first; I had to develop it through practice (and much failure and dead code). I realized after a while developing good UX is not a linear process its cyclic. I'll share some HCI practices that I found worked well for me. These are the steps I usually when making apps for clients or for myself.<p>Before beginning a project I always like to have solid answers to two these questions. They pretty much motivate all my design choices.
- Who is going to use your app? What drives and motivates them to use your app specifically (i.e. why would they use your app and not something else)?
- What do they do right now to solve this problem? What is their next best option? What are the problems with the existing solution?<p>Next I'll make prototypes. Usually I start with paper and pencil or Powerpoint in a very low fidelity. Though it is tempting, I never write a single line of code until maybe a week or two into this process. Right now, your focus should be in exploring as much of the design space rather than committing to one single possibility - nothing is too crazy or outlandish at this stage. Don't use a ruler or be neat - just get it out so you can understand and evaluate it later. Don't worry about the technicalities of how things will be implemented you can worry about that later.<p>Once I have enough ideas I pick my 3 winners. The way I do this depends on the specific problem and its constraints - you should base this on the two important questions I mentioned first. For example, if your user is unfamiliar with technolgy, readability and simplicity might take priority over adding a useful but complicated feature. But if he's a developer, you might keep the jargon and add the features to enhance his experience. Don't stress over this process too much because in the end, this is all just based on just your own educated guesses.<p>Then I make a powerpoint mockup of my favorite idea - basically just slides linking to other slides, with different pictures and animations to make it look like an app. This next step is all about verifying your beliefs and ideas about what you picked. I try to make this as real as possible, adding slides to simulate page loading, using actual iOS or android icons and fonts in my designs but that is a personal choice. Use this mockup to evaluate and test with some users and/or the clients - the things that sometimes you assume or overlook about your users or the problems will surprise you. Consider the feedback and update your assumptions. Now reevaluate your original designs (even the ones you maybe threw out) and fix your mockup. Test it with some users 2-3 times again till no more important issues remain.<p>Now you write your code. This will be your first prototype. Try to be quick and use familiar technology as far as possible. You should have no problems converting your PowerPoint reference to code since you've done it a hundred times before. Add some sort of analytics / tracking so that you can measure important metrics in your app when it comes time to test.<p>Now find a set of users that you would like to test your app with - you could ask friends on HN or Facebook, post on Amazon MTurk or go door to door. Try to get your testers to be as close to the target demographic of your users - ideally your testers ARE your users but sometimes you can't be picky. Show your testers the app and get them to use it. If you can, get them to talk aloud as they use it, describing their thoughts process and action in a think aloud. If you can record this process in a video/audio or screen recording so that you can review it later.<p>Now organize that feedback and analyze it. What is the most common complaint/request your users have right now? Are the problems due to design or implementation? What are the differences between your initial mockup and your prototype and how do they affect the result? Based on this analysis improve your designs, update your code. Do it again a few times if necessary. Once your testers are reasonably happy release it to your actual users and see what they say - chances are by now you should have caught and fixed a lot of the design problems that were too domain specific or hard to discover for you alone and your users will be a lot happier!