
Ask HN: How to become good enough in UX to sell your apps? - rufus42
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&#x2F;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?
======
loumf
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.

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.

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:
[http://jobstobedone.org/radio/the-mattress-interview-part-
on...](http://jobstobedone.org/radio/the-mattress-interview-part-one/) and
then look around that site. Learn about "job stories":
[https://medium.com/the-job-to-be-done/replacing-the-user-
sto...](https://medium.com/the-job-to-be-done/replacing-the-user-story-with-
the-job-story-af7cdee10c27#.mpvd4nqcr)

------
GFischer
Who are your customers? Businesses? End Users? And how much of an improvement
in sales would you expect? 10x?

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

So far it's not as expensive as we feared, but we haven't launched yet.

There's also another thread on Ask HN about it. It basically says to copy and
to practice:

[https://news.ycombinator.com/item?id=10948099](https://news.ycombinator.com/item?id=10948099)

------
JeffreyKaine
Realated:
[https://news.ycombinator.com/item?id=10948099](https://news.ycombinator.com/item?id=10948099)

------
seanwilson
I wouldn't over think it. Read a couple of books, study UIs you use more
critically and keep practicing.

------
dr0w
tldr: iterate, iterate, iterate.

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.

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?

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.

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.

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.

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.

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.

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!

