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:

1. Get a basic working knowledge of User Experience (what it is)
2. 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.

Building and Distributing a Force.com app

Last month, at Dreamforce 2011, I had the privilege of speaking to an audience of people thinking of building a commercial software product on Force.com. Since my company helps this specific market, I was asked to co-present with someone from Salesforce’s marketing group that supports these people in their efforts.

This article is a summary of the material I presented. Here’s a high-level outline:

• Building Your Team and Your Knowledge

• The Build Process: Technical and Licensing Concerns

• Stories From The Field

• OK, Let’s Get Started

I represented the perspective of “someone who’s been through it.” To steer clear of legal issues, I’ll omit details of the content presented by the other person. Here’s a simplified version of my slide deck, with an explanatory article below.

Think Different(ly)

I began with a show of hands asking how many folks in the audience had an iPhone or an iPad. Luckily, I had a significant number, so I was able to use my analogy comparing Force.com development to iOS development. Both types introduce significant new elements—new programming languages, APIs, distribution methods and quality processes.

These new elements necessitate a shift in thinking from traditional Java or .NET development—one which starts in design, affects coding and extends into sales. Directly “porting” an existing application concept to Force.com would be no more successful than porting the entirety of Microsoft Excel to the iPhone. There’s a different definition of what makes an app great.

Concrete Examples

Let’s take the example of building a simple blog system that organizes Articles into one or more Categories: Force.com’s object database causes the fundamental data model to include notable differences. The Categories are defined as a first-class attribute of the Article, rather than as a separate table (requiring yet a third junction table). Moreover, this structure allows the system to render an appropriate UI to assign an Article to multiple Categories without any custom code.

Force.com also includes a major difference at the user interface level: a native, out-of-box UI that matches Salesforce’s CRM and Service apps. The interaction and visual design of most Java or .NET apps will start with a blank slate. The default UI may or may not be a great fit for your app, but in either case it’s worth respecting the conventions to which Salesforce users are accustomed. Reducing friction for end users will drive adoption and word-of-mouth referrals.

Look Beyond Development

The Force.com platform is broad and deep; launching an app on Force.com is definitely standing on the shoulders of giants. Hence, it’s possible that the engineering effort to build an app is actually less than you imagine. That said, most folks with a development mindset don’t plan sufficiently for the work to distribute the app. Working through the Security Review process and listing on the App Exchange are activities that require time and planning.

It’s natural to “go with what you know” and focus on simply building the app. Unfortunately, that’s not the finish line. ISVs would be well-served to start planning for non-development activities sooner rather than later.

The Role of the PDO (Product Development Outsourcer)

Salesforce refers to my company as a PDO (Product Development Outsourcer)—we can design an application, handle the development and help a client through the work of launching onto the App Exchange. On the majority of our prior engagements, we’ve done the lion’s share of the development.

Over time, however, the client team ramps up and takes over. As a corporate asset, the app is their intellectual property and it’s critical to assemble a team with the skills necessary to be a successful software company over the long term. This includes not only development, but also related functions like customer support and product management.

Our model is not to become “embedded” as a vendor for many years. In fact, we’re thrilled to hear success stories from former clients who no longer need our “training wheels.”

OK, Let’s Get Started

If you’re an ISV that’s ready and willing to head down this path, how do you begin? It’s actually quite simple: our usual process is to meet with you and have you explain the long-term vision of your application. We need to understand your definition of success. Then, we’ll discuss any tricky requirements in a little more depth, go back to our offices and reflect on everything we’ve learned. Finally, we develop an overall design concept of what it would look like to host your app within Force.com, and we share the concept with you to get feedback.

It’s analogous to meeting with an architect to design a custom home, describing what you need, and seeing an initial sketch. Almost all the elements in the design are still negotiable, but the sketch gives you confidence the architect understands your end goal.

Most often, our initial sketch takes the form of a concept model. Once you’re comfortable with what you see, we’ll begin a formal planning process and design phase to capture and spec out all the specifics. After the design phase is complete, we scope the actual development work.

If I could choose to have the audience remember only one idea from my presentation, it would be this: prior experience building software will help you succeed on Force.com, but don’t expect to do things the way you’ve always done them. Embrace the change.