Here’s a pretty good resource for learning UX/UI design, if I do say so myself.

There is a difference between UI design and UX design. There is a lot of overlap though, so I’ll try to bundle them together. Here it is, in ten simple steps.

#1 Discover the problem
Far too many designers sit down to work on a new project without doing any research at all. Their thought process usually goes something like this….

No. Stop.

I’m sure your new CSS technique is wonderful but the point of designing an interface or experience is to solve a set of problems. As much as I’m partial to CSS animations and Proxima Nova, these things are more improvements to solutions than they are solutions to problems.

Stop looking at websites and wincing at misaligned elements, native fonts and ugly color schemes. Start looking at websites as solutions, solutions to problems. Problems might include:

–  Not optimized for mobile
–  Not accessible to screen readers or color blind people.
–  12 second load time
–  Value of the app not immediately obvious
–  Too many steps in sign up flow

#2 Get to know your users
It’s much easier to solve problems when you first figure out who is experiencing them. Find out as much as you can about your users before you start.

–  What is their average age?
–  What browser do they use?
–  How did they find your site?
–  What do they want from your site?
–  What does your site want from them?

#3 Learn to wireframe properly
So, now that we know who our users are and what problems they are experiencing, we can start redesigning our homepage, right?

Wrong.

One of the most common mistakes I see in UX design is the reflex to automatically start with the homepage. It’s tempting to guide the user from the homepage to where you want them to be. However, in a lot of cases, the homepage is not always the landing page. Perhaps your blog is where most users begin their journey.

Open a Google Doc. Make a list of all your site’s entry points. Now, starting with the most important entry page, take your pen and paper and start adding content. Let’s pretend we’re wireframing our blog.

So, we need a heading, the article body, the date, th…..wait. Do you really need to add the date? Does the date affect the relevance of your article? If so, add it. If not, leave it out. Keep going until you have all the necessary elements added.

Now you want to start thinking about where to guide the user. Maybe you want them to tweet your article? Maybe you want to show them related articles. Maybe you want to guide them to your homepage? Offer too many options and they will probably do nothing. So choose wisely.

Make sure every single piece of content you add has a valid reason for being there. It must serve a purpose, solve a problem. If it doesn’t, remove it.

Rinse and repeat with all other entry points. Regardless of where the user enters your site, it should be easy for them to complete their tasks and reach the desired goal.

#4 Communicate effectively
It is your job to communicate the information your users want in the quickest, most effective way possible.

Video and images are very effective forms of communication. Study well designed websites and see how they frequently use images and icons to communicate.

Don’t make your users work any harder than necessary. Most users scan websites rather than read them. Give each section of the page a heading, so users can quickly scan to the section they’re interested in. Make sure you keep your headings short and sweet. Experiment until you have effectively communicated what you’re trying to say in the simplest way possible.

Too long winded.

Better.

Bleeding edge.

#5 Guide your users
When a user lands in your app and doesn’t immediately see how it can benefit them, chances are they’re gonna leave and won’t be coming back anytime soon. Don’t base all your design decisions on how the app will perform when it’s full of data. Design the journey.

#6 Encourage your users
When a user makes a mistake, don’t just inform them in a cold manner and leave them to figure out the solution.

If you do this, they will blame you and you will lose their trust instantly. Instead, let them know they made a mistake in a polite, even perhaps humorous way and then point to the solution.

#7 Reward your users
Likewise, when your users do something right, reward them. Don’t just inform them of their success like any robot would.

Congratulate them in a human tone. Reward your users and they will feel compelled to use your product. Make them feel loved. In turn, they will love your product.

When the user’s experience is greater than the user’s expectation, trust is established. Establishing trust as early as possible is paramount to providing a good user experience.

#8 Learn the basic fundamentals (HTML, CSS, JS, Ruby, Python etc.)

Enough said.

#9 Learn visual design
Lots of UX designers think they don’t need to know about color or typography. Others say it’s a complete waste of time. It’s not. The problem is, designers are frequently using visual solutions to solve UX problems. If your users are having trouble completing the checkout process, making your buttons a little shinier is not going to help.

However, assuming you have your user flows in good order, improving your visual design will help your users trust you more.

Gaining a good understanding of visual concepts will not only empower you with the ability to design awesome buttons.

Layout, balance, alignment and contrast are essential skills when it comes to figuring out the most efficient way of organizing information on a page.

#10 Study. Study. Study.
There are countless resources out there for learning about design. Here are just a few to get you started:

Resources
Smashing Magazine
Aarron Walter (aarron) on Twitter
Paul Irish (paul_irish) on Twitter
Responsive Design
Ryan Singer (rjs) on Twitter
Chris Coyier (chriscoyier) on Twitter
www.designskool.com
CSS-Tricks
AaronRobbs (AaronRobbs) on Twitter
Designing for Emotion
Welcome | Voice and Tone
Dribbble – Popular
iOS Mobile Patterns
The Main Tap › PatternTap
Google
Designer News

Awesome Sites
http://mailchimp.com
https://yourkarma.com/
http://facebook.com
http://layervault.com/

Good luck 🙂

See Questions On Quora

I don’t know if this is the type of UX success story you’re looking for, but there was a highly publicized case study of “The $300 Million Button” at Amazon.com (it’s also included in Web Form Design: Filling in the Blanks).

Basically, there was an unknown conversion bottleneck in the Amazon shopping process:

1. User picks out the stuff they want to buy and adds them to their shopping cart
2. User clicks “checkout” to presumably pay for the purchases
3. A form pops up, as it does on many e-commerce sites, that asks the user to Log In or Register.

This simple form caused $300M worth of shopping cart abandonment as many users resented having to register to make a purchase (Amazon originally predicted they would be happy about saving time on future visits with Amazon’s patented “one-click-checkout”), and others couldn’t remember if this was their first visit to Amazon and became frustrated with each failed login/password attempt. The point: no one wanted to click “Register”.

This, despite the fact that the registration form didn’t ask for any additional information that wouldn’t already be needed to checkout with. Additionally, even users who had registered in the past stumbled on the form when they forgot their email address or password.

The fix they came up with was to replace the “Register” button with “Continue” and a message that read:

“You do not need to create an account to make purchases on our site.  Simply click Continue to proceed to checkout. To make your future  purchases even faster, you can create an account during checkout.”

This little change resulted in a 45% increase in completed purchases, and for the first year, the site saw an additional $300M in revenue.

This is one of those classic marketing parables that reminds you to test everything and test often. Don’t just go with “common sense” or your gut feeling. You might not think that having the shopping cart on the right or left would make a big difference, but it can and does. And it can even have different results on different sites.

See Questions On Quora

“Simply increasing the content height” is exactly why the display is larger. The iPhone 5 is better for reading and writing than any previous iPhone.

Here are some examples:

• When writing, I can see a whole paragraph instead of sentences
• When searching w/ the keyboard visible, I can see 5.5 results instead of 3.5
• I can see 6 emails in my inbox instead of 4
• I can see 6 tweets at a time instead of 4
• I can read a whole additional paragraph in an email without having to scroll

If there’s one thing that I hope designers and developers take away from the increased display size, it’s that content is everything and the UI should do an even better job of getting out of the way.

See Questions On Quora

None. Repeat: NONE.

There is not a single major healthcare software company that genuinely cares about its end user experience, despite the fact that poor implementations have, amongst other things, been associated with increased patient death. The particular publication I’m thinking of is actually more reminiscent of a frustrated rant than a calm scientific explication[1].

Reasons why no one cares:

1. No one at the company really understands how to abstract healthcare workflows. The engineers are absorbed in the coding of functionality, the product managers have no idea how their stuff is being used to treat patients, the docs are too busy trying to use this crappy software to treat patients that they tend not to be available to give adequate feedback, and designers who are good are quickly snapped up by Silicon Valley companies who understand how ridiculously valuable they are.
2. There’s a huge barrier to moving away from a piece of healthcare software once it’s been bought and installed, because they’re all pricey and everyone has to learn a new set of workflows. Patient care almost invariably suffers during this adjustment phase, and the last thing anyone fighting in the trenches wants is to screw up a patient’s life.
3. Many morons in healthcare administration still have not figured out that “extreme customization available to fit your practice’s needs” is advertising BS for “we were too lazy to figure out this really important part of our software, but we don’t want to admit it, so we’re going to spin it like it’s a good thing and lay all the blame at your feet when the random crap you pick inevitably fails in some major way”.
4. The backend implementation for many large EMRs would have to change fairly drastically (read: be completely redone from scratch) to modernize it into something that coder-designers of recent generations would even want to touch. To give you some idea, EPIC, the largest EMR vendor, uses Cache[2]. This framework is based on MUMPS, which came out in the 1960s before humankind even knew what good programming methodologies were. Example for you programming types: there is no variable scoping in Cache. Let that sink in for a minute. Yes. All variables are globals. It is an unholy nightmare.

[1] http://www.pediatricsdigest.mobi…
[2] http://en.wikipedia.org/wiki/Int…

See Questions On Quora

1) Don’t cut functionality. If it’s available on a real computer, make it available on mobile. More and more people are foregoing computers and only using tablets and phones. This is a shockingly common failure:

• YouTube failed this one epically by blocking half their content on mobile.
• Urban Spoon won’t let you put titles on restaurant reviews that come in through mobile.
• Wikipedia’s mobile pages do not include category tags, although at least it’s easy to switch over to the real webpage.
• I’ll list more as I think of them.

2) Mobile should be one (important) part of a platform-inclusive strategy that comprises computers with large monitors, laptops, netbooks, tablets, minitabs and microtabs, phones, “smart” TVs, and unforeseen new devices. The four most important form factor reference points would be:

Full-scale (PCs and Macs)
Mid-size (Tablets, Chrome/Netbooks)
Transitional (Minitabs – 6-8 inch tablets)
Pocket (Phones and microtabs aka “phablets”)

You should have designs for all four of these form factors as they represent distinct use cases with very different capabilities, and be able to transition between them smoothly with “responsive” design. This allows you to accommodate unforeseen form factors that fall in between without having to create a separate design for every single aspect ratio and size.

Nota bene: If you’re pressed for time or budget, focus your energy on the tablet experience. For many, that’s replacing full-scale computers, and in any case it splits the difference between mobile and PC so should be bearable on both.

If you cannot afford to develop separate mobile and computer UX, split the difference and design for tablets. A tablet site should function largely like a full computer site except for (A) suitability to portrait and landscape modes, (B) absence of hover functionality, and (C) distinct button-like delineations on hyperlinks.

3) How to decide whether to do a native app vs. a web app or website. Apps take up space on people’s phones or tablets. They are yet another object to keep track of for the user. This is why Google even built a notebook based on the principle that no applications would be stored locally. Assume you should first build a web app or website UNLESS:

a. The product is dependent upon nuanced UX functions best standardized to one device. E.g. anything with gyro or motion sensing.

b. The product uses a lot of routine, predictable CPU cycles that aren’t dependent upon outside data, cycles that are best processed locally rather than sent through your cellular service. E.g. a graphically intense video game without multiplayer or a calculator.

c. The product is likely to be used in an area without cellular or wireless internet or where the absence of said would be disastrous. E.g. a guide to edible plants, a flashlight app,

d. A product where speed and instant accessibility are paramount. E.g. a camera or sound recording app.

As for offering a native version of existing web functions, use the rule of thumb that unless a plurality of users are likely to put it on their phone’s home screen, it’s not worth the cost.

4) Otherwise, web first, app second. I can’t tell you how many clowns there are out there who make an iOS only app that is perfectly well suited to a website (see above) when they should have made a regular old website. It completely cuts out Windows, Mac, Android, and Blackberry users. An app that should be a website is a hipster conceit.

Take a look at Instagram. You cannot view your stream on a computer. It’s absolutely ridiculous. Aside from the problem of lack of accessibility, a user may wish to edit their photos on a computer with its superior UI instead of their finnicky phone.

5) No small or tightly spaced controls. Ever.

6) Make it work in landscape mode. Some people use phones with a built-in keyboard which automatically switches to landscape mode when the keyboard is deployed. Minitabs and microtabs, due to their size, may see users preferring mobile sites rather than iPad-optimized sites. For now, just about everyone who uses a mini/microtab is going to use it in portrait mode however if they make a keyboard expansion for Kindle Fire, that may change.

My GMail app does something astonishingly stupid in landscape mode: it increases the size of the font. This means only two lines of text are visible. Clearly someone did not put any thought into this.

7) On a mobile website, link to the full site at the TOP not bottom. Do not hide it, whatever you do. Conversely do the same on the regular site linking to mobile.

8) Bulletproof code. Yeah, I know. This isn’t a UI thing, but code quality obviously affects the UX. Mobile devices are already inherently more annoying to use than a real computer. The slightest inconvenience caused by a defect could infuriate the user. Oftentimes, a mobile app will be used under more stressful situations than a computer program which is likely to be used by someone at home or at least somewhere they can set up a laptop.

9) Test your app out in the worst circumstances. Fingers numb from the cold or from having sat on your hand, dazed having just been woken up out of stage 4 sleep by an alarm clock, driving down in heavy traffic (technically I can’t recommend that but let’s be real here), while intoxicated or stoned, or under heavy stress of any sort.

I know there are others but those are huge.

See Questions On Quora