User Experience 101 for Developers

At Dreamforce 2012 in San Francisco, I lead a conference session that I called User Experience 101 for Developers. As the name implies, this session was targeted at developers with no prior knowledge of UX (User Experience). I had two primary goals for this session—the attendees would:

Get a basic working knowledge of User Experience (what it is)
Learn a lightweight User Experience Design process they can use to improve the next thing they ship

I feel this is relevant since the lead developer becomes the de-facto UX designer on teams with no dedicated UX practitioner.

With that in mind, here are some concise notes you can use if you’d like to refer back to something I mentioned.

What User Experience Is (and Isn’t)

First, a visual analogy using cereal
It’s about understanding what your users need to get done, and then adjusting the interface so they can get it done in the best possible way.
Keep the scope and features profitable, feasible and desirable.
It’s not limited to any particular platform: UX design applies to standard Salesforce, custom apps powered by Force.com or any app built on Heroku.
It’s not about fancy graphics or “jazz hands.”
It’s not about sitting in a coffee shop waiting for brilliant inspiration.
As developers, you’re in the best position to know what’s possible, and actually make something great that people really use.

Research

On a scale of 1-10, how painful was your last requirements gathering session?
Wouldn’t it be better for the users to tell you stories about what they actually needed to get done? What’s behind that requirements spreadsheet anyway?
Activity: Ask the person next to you what they wanted to “make sure of” the last time they checked the weather online. What were they going to then do? Interview them, documentary style, for 2 minutes, then switch roles.
This works in shorter bursts, but it can get tiring for users… and they may not answer questions that well anyway.
Driving analogy: the user is driving though their day, doing one thing or another. They’re not processing and remembering everything they see or do. They can’t really explain it.
Instead, “ride shotgun” with them and watch what they do. Also, notice what’s on their desk and what the sticky notes on the monitor say.
Speaking of sticky notes, one observation per sticky is a good way to capture what you learned. Later, group stickies together that relate in the user’s mind.
If you can’t be in the same cubicle, watch them via a web meeting.
After all this, you’ll have a deep, real-world understanding of the “so that” on your agile story cards. That’s what you want.

Ideation

Most requirements come from the MSU method: Making Stuff Up. Requirements are an input to the design process. Your new observations and understanding is another, and your budget is the last (main) one.
Take requirements as a starting point, then work up better alternatives. Reference UI Pattern Libraries, which are similar to Design Patterns in the world of coding.
Often times, its not that hard to come up with better interaction concepts now that you understand the user’s real goal. How much can the system do for them…can you skip or combine steps? Can you drop certain feature ideas that don’t tie back to any goals? (Refer to your observation sticky notes.) What does the platform do out of the box?
6-up templates are great for exploring ideas cheaply with pen and paper. Check out Dan Roam’s Napkin Academy to bone up on sketching basics. Trust me—it’s not that hard, and you don’t need an art degree.
If you want to play with ideas in higher fidelity before coding, check out Keynotopia or Keynote Kung-Fu. Different fidelities are useful at different stages of the product. (Lower fidelity early on, before things gel. Then, go higher fidelity later.)
Also consider platform-specific approaches (that users wouldn’t suggest) like standard page layouts and VF tags in Salesforce, or UI frameworks like Twitter Bootstrap or ZURB Foundation when using Heroku.
After trying some alternatives, combine the best ideas into something cohesive that flows smoothly, again measuring against the user goal. Interactive Sketching Notation can be used with paper or high-fidelity renderings.
Speaking of flows, why not just build a prototype of the idea? That way, you can just click through the flows for real. With Force.com and Heroku, you can piece together something clickable very quickly. This is helpful if you have a more radical concept. ”Show, don’t tell,” as they say in Hollywood. Ideas don’t sell themselves, unfortunately.

Evaluation

On a scale of 1-10, how painful was your last UAT session?
UAT has the wrong connotation and implies users can reject the entire app (if they don’t “accept” it), but there’s never enough time in the schedule to account for non-trivial requests.
Good news: since you have a much better idea of what the user actually needs, you’re a LOT more likely to get change requests and surprises at this stage. It’ll still happen, but it’ll be clearer you were working from inadequate information.
Prepare for feedback of some kind. You’ll almost always make SOME sort of change. Nobody’s perfect. Don’t worry…80% of these changes are cosmetic (according to Salesforce).
If you have a good relationship with the users, you may be able to show them early mockups or sketches and quickly take their temperature on an idea, even before it’s fully baked.
If not, slowly work up to this by presenting clickable prototypes (thus building goodwill). Emphasize how users would flow through the screens and accomplish the goals you discovered earlier on.
If you’re working with a user that hasn’t been deeply involved to date, this is an opportunity for Usability Testing. Don’t be a “talking manual.” Get them oriented, then see if they can complete their tasks. Make it clear you’re testing the software, not them.
When you get feedback that doesn’t seem relevant, ask how it relates to the original goal. There’s a fair chance you didn’t get the full story, so something important may be missing.
If it’s just a bad idea, say “we’ll get back to you.” Then, render it quickly and show that it’s bad. Don’t just tell them it’s bad.
Remember when you asked your partner why they checked the weather? Compare that to the Dark Sky app. How does it stack up? Were they going skiing? Were they packing for a trip?

Takeaways

Fill in the “so that” part of your User Stories by riding shotgun with your users. Only when you understand their goal will you have a starting point for your design work.
Start with the requirement or the obvious approach, then try at least a few other different concepts. Next, combine the best ideas into something cohesive.
Build prototypes and test them with users, then tweak when you find non-trivial issues. You can’t beat Force.com and Heroku when you want to get something clickable out the door fast.