“Spaces” Don’t Exist

You can’t swing a dead cat at this year’s CES without knocking over a booth full of “wearable” technology. You’ve probably heard of Google Glass, but did you know you can also buy a drum machine t-shirt, solar-powered bikini and jeans with an embedded keyboard and mouse?

No doubt about it: wearables are one of the hottest “spaces” right now. I see only two problems:

1. There is no such thing as a “space.”
2. It doesn’t matter if the products are wearable.

Spaces Don’t Exist

The term “space” is a product of lazy, muddled thinking. I can’t say it better than Marc Andreessen:

There is such a thing as a market—that’s a group of people who will directly or indirectly pay money for something. There is such a thing as a product—that’s an offering of a new kind of good or service that is brought to a market. There is such a thing as a company—that’s an organized business entity that brings a product to a market. But there is no such thing as a “space”.

If someone tells you that “space” is hot, ask them who exactly will buy these products, and what hole it will fill in the buyer’s lives.

Categories Don’t Matter

Whether something like Google Glass is wearable may or may not be relevant to what it helps me do. Mat Honan spent the last year using Glass and identified some concrete usage for it. I’ll pick one example here and phrase it in terms of a job story (a term coined by Alan Klement):

When I’m with my child and (s)he does something cute, I want to take a photo quickly without retrieving a device so I can stay engaged while capturing the moment.

Couldn’t something like Dropcam with more advanced face detection perform this job? How about other products currently focused on security monitoring? It’s not important to me that the device doing the job be mounted to my head, as long as it gets done. In fact, I may prefer nothing on my face.

The interesting products from this year’s CES will address underserved jobs-to-be-done. They need not be attached to your body.

The Testimonial Pipeline: Get Reference Customers Like Salesforce

I know we just met, but will you buy my product right now? Can I put your picture on our web site as a happy customer?

No? Maybe next time.

Growing Reference Customers

A customer testimonial does not magically appear on your web site. Your relationship with them starts as a seed, and their success blooms the more your product’s value nourishes the plant. With a little luck and a lot of hard work, some of those blooms will be worth showing off.

So how, exactly, do you obtain a testimonial? Well, Agile development, by itself, won’t cut it. Marty Cagan’s “Inspired: How To Create Products Customers Love” helped me understand that shipping code every 2 weeks without changing how you engage customers gets you no closer to making them successful. Sprinting through your backlog does not create more customer value than waterfall if you dreamt up the feature set without validating demand or testing your designs. Agile offers no specific structure to engage customers, especially for revenue products with buyers outside your company.

Salesforce.com is a useful case study, since they’ve published over 100 customer success stories on their web site. They engage customers at many different points along the timeline of product development, creating what I call The Testimonial Pipeline.

The Testimonial Pipeline

A testimonial pipeline has multiple stages, similar to a sales pipeline. And just like sales, not all the customers that enter the wide end of the pipeline will come out the other side as a reference. (Repeat: you will not bat a thousand here. Manage expectations.) The stages are as follows:

• Interview Subjects
• Usability Testers
• Beta Participants
• Reference Customers

Anyone you talk to starts as an Interview Subject, even before they’re a customer. Talk to real people as early as possible to get a deep, rich understanding of the demand for your product/idea. If you have paying customers already, you should obviously talk to them as well. The way you refer to these folks is less important than what you call them.

Product managers and user researchers at Salesforce.com take the lead at this stage, and reach out to people via many channels. You want to get people on the phone or meet them in person, though you can often make an initial connection via social media. Feel free to validate early design ideas as well as the underlying demand, even though it bleeds into the next stage a little.

If there’s sufficient demand and a design idea is around 60% baked, you can have some people play the role of Usability Testers. In short, you ask the person to complete a task inside your user interface and gauge how successful they were. An interesting twist Salesforce adds: they make small improvements to the design between each round of testing. Don’t be rigorous about maintaining a control group and experimental group: the goal is to improve the design as quickly as possible.

Once the concept has matured into working software, some brave souls can test it “in the real world” as Beta Participants. When customers put the product through its paces in their own environment, you start to see the value it (hopefully) creates for them. Salesforce proudly announces which brave companies participate in their critical beta programs; usually any code is feature-complete, though it likely contains some bugs.

If these folks continue to see value after the product is generally available, they can (finally) become Reference Customers. This manifests itself for Salesforce in a number of ways: on their web site, as reviews on their AppExchange, in YouTube videos, and even in traditional print media. Their customers are the heroes of these stories.

But I’m Not Big Like Salesforce

If this all seems daunting, I have good news: you can get started today just by picking up your phone. Call someone and ask them about that idea in the back of your mind. All you have to do is have a conversation. If you want to put just enough process in place, refer to The Entrepreneur’s Guide to Customer Development and Lean UX.

Know you need to get out of the building, but having trouble with buy-in? Show your stakeholders these examples from Salesforce.com and frame it up in terms of getting reference customers and increasing sales.

And who wouldn’t want more sales?

Speak to Existing Demand

Stop talking about the features of your product. That’s “supply” thinking. Focus on the demand that actually exists in the world and aim your product or service at that.

How to Build a Theory

Long story short, you expand and refine your theory when you find an anomaly, thus making the theory stronger. (More here.)

Writing Requirements on Wood

Not long ago, we had a contractor finish our basement to create a play space for our daughter. Since my life is a continual series of software projects, I was curious to see what I could learn by observing a real-world construction project. Overall, it’s got a lot in common with Lean UX.

The Three Key Lessons

The connection occurred to me when I was reflecting on our experience at Lean Day West this week. Our team had a front-row seat for insightful talks from Bill Scott, Farrah Bostic and many others. Jeff Gothelf posted his list of takeaways from the event, and we have a few of our own.

Document just enough, just when you need it

The contractor in our basement project wrote things down at the right moment, at the right level of detail, in the right place. In this picture, he left some notes for a carpenter written directly on the correct material to use, listing the tasks and placed in the spot the work needed to be done. It was a map, a task list and a spec all in one.

Are the documents in your company doing triple duty? How well do they help the next person complete her tasks? Do they just capture the decisions of the stakeholders? If the document was a person, what job would it be hired to do?

For the plumber, our contractor marked where to drill by drawing right on the concrete using the biggest Sharpie I’ve ever seen. I tried to get a photo of that as well, but they were too efficient (!) and started working before I had the chance. The X didn’t exist five minutes before it was needed, and didn’t exist five minutes after either.

In my experience, writing a detailed spec long before it’s executed is a fantastic way to waste tons of time. You’re wrong in ways you don’t even understand yet (you’re listing your assumptions, right?) and you don’t have the build team’s attention anyway. They’re busy with what’s needed for this sprint.

Use experienced people

The tradesmen were able to get by just fine without a 50-page spec partly because they were all talented, experienced professionals. They didn’t need to be spoon fed.

Similarly, prototyping and hypothesis testing isn’t a great place for rookies unless they’re as fast as someone with more experience. If you’re truly being Lean and prioritizing learning over building, you need to work quickly because you want to fail as fast as possible. Odds are, you’ll spend too much time explaining things to The New Guy.

Small teams, close together

There were a number of hectic but critical days where the trades were all together, working side-by-side in my basement. The plumbers and electricians performed a particularly intricate dance to hook up the vanity in the 5’ x 8’ bathroom. Goofy as it was, any other approach would have been far less efficient.

Are there times when many hands make light work? Sure. In the case of the basement, a team of painters with fancy spray guns attacked the walls and finished in two days. But that’s the exception rather than the rule; most jobs simply can’t be split a dozen ways.

Stay Lean and Mean

Are you building a product and running Lean? Gather a small team of experienced people and give them the info they need at the right moment. It’s “easy, peasy, lemon squeezy,” as my daughter likes to say.

Then she runs down to the new basement and makes a mess.

Agile Has No Brain of Its Own

Agile development has no brain on its own. Feed the machine with a Lean UX process. (More here.)

Don’t Blow Up the Whale. Ask “Why?”

A recent issue of the MIT Sloan Management Review has a great article on asking “why?” in a corporate setting, as opposed to blindly acting or making assumptions. They also outline the most common reasons why this doesn’t happen:

• The action bias: Deadlines are always approaching, so teams often leap into action before the problem is fully identified and assessed.

• The familiar solution: “Well, I guess we’ll do what we always do.”

• Myopic view of the cause: It’s tempting to assume a single, easily identifiable factor is the cause of a given problem.

• Unresolved conflict: Most company cultures are such that disagreements on direction can’t be resolved in the conference room, though they are voiced at the water cooler immediately afterwards.

• A hidden agenda: On occasion, a single small subgroup can push an effort forward that doesn’t benefit the wider organization.

• Other distractions: Many teams are simply moving too fast to think clearly and recognize higher level issues. If you’re driving 100 mph and spinning out in every corner, you can’t think ahead. You’re just reacting, hoping to avoid a crash.

The article is full of great anecdotes, though my favorite is the story of the Oregon state highway engineers using dynamite to remove the carcass of a gray whale from a beach in a tourist area. This did not work well, but they used dynamite because it was their go-to solution for removing boulders from the road (#2 above).

User Experience Design for Mobile

As part of Salesforce’s “Summer of Mobile” webinar series, I presented a session on user experience design for mobile. This post is adapted from that webinar.

Mobile device use is exploding, but people can only make time for about 5 new apps every month. So as a business that wants to jump on this trend, how do you build a great product that sticks with users?

In our work at Appiphony, we use a four step process:

1. Get Out of the Building
2. Define Success by Writing the Script
3. Build the First Prototype
4. Iterate Until It’s Great

This post describes the use of this process on a real project we executed for a particular Salesforce ISV.

Project Overview

Our client provides physician staffing services to emergency departments across the United States, and wanted to dramatically increase the quality and quantity of feedback they received on physician performance. (Their baseline was a paper form in the mail with a single-digit response rate.) They had a vision to deploy iPads to the emergency departments (EDs) and get feedback in real-time.

Get Out of the Building: Customer Research

As soon as you reach an initial consensus on the product concept, perform a site visit to a location where the app will be used. You need to build an understanding of a setting to gauge how the app will fit within that setting. And based on the questions they will later ask, the rest of your team wants to understand this fit, too!

We visited two separate hospitals and observed the flow of patients in the ED. Seeing the physical location helped us understand how the patients would be able to give the desired feedback. (More on that later.)

If you want to get out of the building but don’t quite know how, check out the book Rapid Contextual Design. It’s a detailed playbook for site visits that also provides process options for small, medium and large budgets.

Define Success by “Writing the Script”

Once you have a handle on the setting, write a plausible story starring your customer succeeding at something with your app. Ideally, this story will take place in the setting you studied. (It will be much more realistic that way.)

In contrast, don’t ship features that don’t connect in a coherent way for the user. “Stick to the script” and leave out what doesn’t fit. And if you’re worried about leaving things out, don’t forget you’ve got 80% less screen real estate on mobile.

Our script is shown below in the form of a storyboard. It turns out patients have down time in the treatment room after they’ve been helped but before their prescription is ready and they can leave. And here’s the key detail that drove this home for our team: there are TVs in the treatment room to kill this extra time. We never would have learned this without the initial site visit. With that, the dev team truly “got” the concept and was 100% on board.

Start by writing your own story in words, and if you’re unsure how, About Face by Alan Cooper will lead you through the process. I recommend you make the story visual with a storyboard or comic, and for that you should read See What I Mean by Kevin Cheng.

Build the First Prototype

Now that you have a vision of success, it’s time to build your first prototype. Do this as quickly as possible, since you will change the UI, probably in a significant way. If you’re developing on the Salesforce platform, you can use the Mobile Packs to deliver something clickable quickly.

Prototyping is absolutely critical on mobile; one poor interaction detail can kill your whole experience. In our case, we ran a quick-and-dirty usability test with an elderly relative and saw him get stuck with part of the interface that required scrolling. We took it out and reworked the core navigation mechanism.

If you’ve got a sense for what the app needs to do, but aren’t sure how to lay out the screens, consult a pattern library reference such as Designing Mobile Interfaces. A resource like this lets you flip through well-documented solutions to many common design problems.

Iterate Until It’s Great

The last step is really a beginning of sorts: once you have something clickable that can stand on its own two feet, you can begin iterating with representative or actual users. And yes, you will need to iterate. It’s like preparing for the SATs:

• You don’t want to “walk in cold.” (Some kind of practice is critical.)
• Feedback will improve performance, but only if it’s specific. (Should I work on my essay writing or reading comprehension?)
• Many external resources are available to drive improvements; the key is realizing “better” is possible and planning for it.

Allow for room in your project schedule to polish the interactions and flow from screen to screen. This is critical, so I’ll repeat it: make time up front to revisit the same functionality across multiple sprints to account for the tweaks you’ll need to make. On our project, we made nine (!) prototypes of the key flow before we reached the shipping version.

The New York Times bestseller The Lean Startup has popularized iteration, so many people will be familiar with this. Take a look at a related book called Lean UX to learn more about how to rework your team’s processes to account for iterative cycles.

If you’re curious about how exactly to apply polish to a user interface feature, a book called Microinteractions describes a framework for approaching this and shows many successful examples.

Functional, Social, and Emotional Jobs

Have you ever been watching a game show and found yourself screaming at the TV because you know the answer to the question, but the contestants don’t? That’s how I felt listening to a recent episode of NPR’s Planet Money podcast. It’s a great show that boils down complex economic issues like the European debt crisis into digestible narratives.

But on this one, they missed the boat.

The Topic: Labels

The topic of this particular episode was the effects of labels on product purchasing, starting with the example of generic pharmaceuticals. The story on generics asks why anyone would buy a brand name like Tylenol or Bayer instead of the generic version with the same active ingredients. The imprecise conclusion they report is the following: consumers waste money on a brand name when they lack information and don’t understand the goods are identical.

This is only true if you assume consumers evaluate products solely based on their function. In reality, every product has three components in the eyes of the consumer:

• Functional: As the name suggests, this is the core function the product performs for the consumer. (“How clean does the detergent make my clothes?”)
• Emotional: This is how the product makes the consumer feel. (“This detergent makes me happy because it reminds me of my childhood.”)
• Social: This is how the product affects the consumer’s relationship with other people. (“When people see the detergent bottle and notice it’s a ‘green’ product, I’ll look good in their eyes.”)

A product that costs more primarily due to emotional or social factors could also be called a luxury product. There may be some small functional differences between the Casio MQ24-1B2 and the Tag Heuer Monaco Calibre 36 but not enough to explain why the former costs less than $10 and the latter costs more than $10,000. They both tell time, but somehow Tag Hauer can charge 1000 times as much. Or, you can take a page from Apple’s book and sell a higher volume of affordable luxury items.

The lesson here for product teams is that if you want to charge more, focus on the emotional and social components. (Better that than becoming a commodity.) Despite the fact that you could email your friends photos of where you are, Facebook bought Instagram for $1 billion. And despite the fact that it’s easy to set up a free web site, Yahoo! bought Tumblr for $1 billion.

So how do you understand the emotional and social impact your product has on your customers? Simple: go talk to them. You need real stories of purchase and usage to get this right. And don’t forget this isn’t the same as market research…that focuses on feelings about the brand, whereas you need to access the feelings about the product.

Taking the next step

The method of analyzing a product by its functional, social and emotional components is another aspect of the Jobs-to-be-Done framework. You can learn more about this at the workshops hosted by Bob Moesta and Chris Spiek.

What Is a Requirement?

What is a requirement? How would you define it? Is it…

• a need that a customer has?

• something a key stakeholder wants?

• a raw idea from someone on the team?

• a detailed description of how something should be built?

• a specific solution someone has in mind?

It’s all of those, and none of those. Since a “requirement” can’t be defined in any useful way, we can’t point to something and say, “yep, that’s a requirement.” How many years has the technology industry been building things without a clear, shared definition of this word?

Let’s say you’ve “captured” a requirement or “gathered” it and you’re holding it in your hand, staring at it. What exactly are you looking at? It’s a bunch of words that fell out of someone’s mouth. That’s it.

What do you do with all these words? If you’ve got a big list full of them, how do you move forward? Well, I recommend you print them all out, bundle the pages together, and feed the pages to a goat. That way, at least the goat gets something out of it. Then, go figure out what would actually help your customers.

Credit: Jake Fleming

But I Already Know What It Needs To Do

Let’s say you’re not going into uncharted territory and you already have a good idea about what the product needs to do. OK, that’s cool. Gather your team together and tell them a story of a better tomorrow in which your customer is the hero and they’re succeeding at something using your product.

Kevin, who works the counter at the coffee shop, can take a credit card payment much faster using the new point of sale system. Finally he can focus on making the best espresso possible.

This is what we (and others) call a scenario. It’s a plausible story about a customer using your product in the future to create a positive outcome. Here’s another one:

Kevin moves quickly and sometimes makes a mistake with the register. Fortunately, it’s easy to void a charge and refund money to a patron’s credit card.

The two scenarios above could be grouped together under a capability called Accepting Credit Card Payments. After all, it’s not feasible for the coffee shop to advertise that they take credit cards unless they can both charge them and process refunds. Continue by listing all the scenarios you plan to enable in this release of the product.

Once you group your scenarios into capabilities, it’s usually pretty clear which capabilities need to ship first. The key is to not deliver a feature until your customer can walk through all the scenarios under the same capability. Put dates next to each of the capabilities and you’ve got yourself a release schedule. Congratulations! Your engineers can get started.

Epilogue

Tony Ulwick’s insightful book What Customers Want helped me realize requirements don’t exist. He advocates an even more rigorous method of determining a product’s feature set against a set of quantified outcomes (e.g. “Clerks can ring up patrons 50% faster with our new point of sale system”).

Check it out if you want to dive deeper.

Teaching Design to Engineers

Designer and Lean UX pioneer Lane Halley posed this question on Twitter:

What do you think? How much UX can and should a “full stack developer” know? laurencegellert.com/2012/08/what-i…@carbonfive

— lane halley (@thinknow) June 7, 2013

The article linked in the tweet states that the true “full stack” developer should have knowledge starting down near the metal, stretching up past the UI, into the user experience and beyond, into the business. (I’m exhausted just thinking about it.)

I fear the person asking this question will not get the outcome they want. Knowledge by itself can’t be a bad thing, though in my experience motivation is the real source of magic. I have some strong opinions on this, because I’ve been fortunate enough to see the results when engineers become excited by shipping products others will value, instead of solving puzzles for their own enjoyment.

The engineer mind

Solving puzzles is where it all starts. When today’s programmers were children, they enjoyed building with Legos, working hard until the pieces fit together. Tomorrow’s programmers are ignoring their meals and debugging their Arduinos as I type this. Why? Because it’s fun! At least, they think so.

Actually, let me rephrase that: It’s fun for them. They extract enjoyment and learning from it, and those positive outcomes go into their hearts and minds. Even if they’re just passing the time, the critical distinction is the activity is about them and not another person.

Can you hear me now?

Here’s another example: the recently released book Exploding the Phone: The Untold Story of the Teenagers and Outlaws who Hacked Ma Bell tells the story of the teens and twentysomethings who figured out how to “hack” the phone system and make free long-distance phone calls in the 1950s-1970s. The author stops to make the point that these kids had no one to call. The goal was not to save money or stick it to The Man; they just wanted a challenge.

Here’s one anecdote from the book: the pranksters called several military facilities and were busted by the FBI. Since this was the Cold War era, the authorities thought they uncovered a ring of spies. The interrogation was intense, and only ended when an AT&T engineer produced records proving the kids had made no calls of any possible value. The G-Men couldn’t wrap their heads around the fact that the kids would spend so much time reverse engineering the system without a “real reason.”

But, to them, they had a reason: it was fun. And they learned something.

The big shift

Product teams need to take talented people like this and get them to build something that someone else will use and like, whether or not it’s an exciting technical challenge. By hook or by crook, their focus needs to move outward into the messy world of people and their problems. And, since comparatively few organizations are truly design-led, it’s incumbent upon designers and product managers to build bridges to these awesome folks and activate their amazing potential.

The good news is, it’s possible. I’ve seen it happen; it’s incredible. In our case, a key front-end engineer attended a design conference, and our seating chart worked out such that he sat back-to-back with our (also incredible) visual designer. Before long, the two of them were working on ideas of their own, and we were shipping stuff that was both well-designed and well-built.

That success inspired me put together a UX “crash course” targeted towards developers. If you have a roomful of developers, I’d love to share that message again. I truly believe the single most effective way to improve your organization’s products is by getting the engineers to care about design.

TL;DR

If design isn’t a big part of your company’s culture, don’t worry about how much engineers know about design and user experience. Building things for others isn’t why they started their career. Get them to care about shipping things others think are great, and backfill the knowledge they need a little at a time. They have to want the knowledge before you hand it to them.

Questions are places in your mind where answers fit. If you haven’t asked the question, the answer has nowhere to go.

— Clayton Christensen (@claychristensen) August 3, 2012

A Template for the Jobs-To-Be-Done Timeline

Clayton Christiansen is as high-profile as a business school professor gets, being the author of the only business book Steve Jobs ever read. And while his work on disruptive innovation has been hugely impactful, there’s another aspect of his work that any business can use: the Job-To-Be-Done.

Much has been written about Jobs-To-Be-Done Theory, but the core concept is simple: behind every product purchase is a certain “job” the buyer needs to get done. IKEA, for example, has had great success orienting its business around a consumer that needs one or more rooms furnished in a hurry. And there’s the classic story of a fast food chain discovered adults buying milkshakes as a drive time breakfast substitute. Understand the job and you’ll understand the demand for your product.

One of the best methods to identify the job your customers are looking to get done is to use The Timeline. The Timeline is an interview technique in which you step the interviewee through one particular instance of a given product being purchased and used. It begins with the first thought they consumer had they needed a product similar to the one they bought, extends through using the product, past the “honeymoon period,” and evaluating their satisfaction in retrospect.

Like any timeline, the Jobs Timeline has certain key points on it, and between those are phases. The following is a quick run-through of how to use the template and run one of these interviews.

Tip: When you sit down with your interview subject, set expectations by asking them to pretend you’re filming a documentary about this purchase. Your interview will be much more fruitful if you can “move their mind” back, so warm up with questions on where exactly they were, what the weather was like, and so on. Put them back in the past.

The First Thought is aptly named, and defines the beginning of the Timeline. It’s not a great place to start the interview, however. If you start at the purchase and work backwards, you’ll get much better information. If you simply ask people when they had the First Thought, they’ll answer the question multiple times, and each time this event moves backwards in time. This makes the interview feel choppy. Work backwards and you’ll get there.

“I liked my car when I bought it, but I remember one cold day it felt really drafty and I realized the mileage was getting up there.”

After the First Thought, the person goes into a Passive Looking mode. They’ll have their eyes and ears open for potential matches to their need. Jot down anything they noticed or remember relevant to the purchase during this time. Maybe they noticed an advertisement for a possible solution. (Note to marketers: this is a good time to advertise to them!)

Eventually, something happens that pushes the buyer into an Active Looking mode. This thing that happens is captured as Event 1. Capture this.

“My friend and I originally bought our cars around the same time, and he got stuck in the city because his wouldn’t start.”

In this phase they may compare options online, read books or magazines, and ask friends about the issue. They’ll generally expend much more effort investigating the options. The options the consumer identifies are known collectively as the Consideration Set. This is your competition, so ask about this. Make notes on what they compared, and how. You’ll probably be surprised how products “outside your category” are in the running in the mind of the consumer. (Customers don’t care how you’ve segmented your market.)

More time passes, and sooner or later another event happens (Event 2) that causes the buyer to set a deadline for the purchase. Jot this down as well, and look for patterns among buyers.

“When we saw the check engine light on our car, we knew we’d be going to dealerships that weekend.”

During this Deciding phase, the consumer makes Trade-offs among the criteria they identified earlier. Capturing these trade-offs is critical, since it gives you real insight into what your buyers think is important. Record how the buyer ranked them. Cost over quality? Speed of delivery? What actually mattered?

Before long, the consumer makes the Purchase and simultaneously sets their own expectations about what it’ll be like to use the product. The Consuming period after the buy is a continual evaluation against those expectations. Capture which item they ended up purchasing, and prepare for the interviewee to flood you with details on what it was like to use the product and whether they were satisfied.

Satisfaction surveys tend to focus on the buyer Looking Back at this point and reflecting on their purchase. If the interviewee purchased your product, you may get a few good nuggets of info in this satisfaction discussion. Outside of that, satisfaction reports are overrated because value is defined in the customer’s mind Going In as part of the steps leading up to the purchase. Understanding how the buyer built up their definition of value is usually much more valuable from a strategic perspective. Put another way, understanding how well a product met a certain consumer demand is not the same as understanding the demand itself. Don’t make the mistake of confusing the two.

After the Interview

Even a handful of these interviews will get you deep inside your customers’ heads and fill in your understanding of what they’re trying to get done. Armed with that information, you can build new features or create entirely new products that address a demonstrable need. Minimally, you can tweak your product’s marketing to make sure you’re truly speaking to customer concerns.

Tools like these that build an understanding of the customer are critical for product teams. Without them, they’re simply flying blind—guessing what current customers value and what would attract new ones. Do a few of these interviews and share the results with anyone that touches your product. If departmental silos have hardened in your organization, try the sledgehammer of customer insight.

“Architecture” in Software

What does it mean for a person to be an architect of a piece of software instead of a building? What does that person do, exactly?

My favorite definition of a traditional architect is someone who guides the construction of a building through writing, sketching, drafting, model-making and collaborating. This is not, however, an accurate description of most software architects. And because of this, all of us that use software are worse off.

The garden variety software architect is more akin to a structural engineer in construction, focusing the structure’s serviceability, performance under extreme conditions and other deep technical details. These are worthy pursuits, to be sure. But all too often, no one is deliberately designing how the user interacts with the software and how it will meet her goals.

Software desperately needs more people that actually guide applications toward those goals using the methods of a “real” architect:

• Writing (especially storytelling)
• Sketching
• Drafting (producing detailed specs if necessary)
• Model-making (prototyping)
• Collaborating

Software is not about code any more than the Eiffel Tower is about iron. Lead your team accordingly and call yourself whatever you like.

Wearing the Empathy Suit

Chrysler’s empathy suit

Let’s go out on a limb and say most minivan buyers have multiple children, and many of those have at least one child that needs a car seat. If your family is still growing, what’s it like to actually use a minivan?

Chrysler’s new Test of Ownership ad campaign focuses on the daily user experience of their minivan, and shows how their team uses a pregnancy-simulating “empathy suit” to test the van’s features.

Often times, the team designing and building a product is not part of the target audience. It’s easy to forget this simple fact and miss your customer’s mark by a wide margin. Be prepared to go out of your way to test that your product works for people.

Apple Designers Inspired by Braun

What inspires Apple?

I encountered this vintage Braun phonograph at aosta furniture + decor in Chicago. I’d heard that many Apple hardware designs are inspired by mid-century Braun products, but I’d never seen one in person.

The inner gray rectangle (the turntable) is almost exactly the size and shape of an iPad. The roundness of the corners is very familiar as well.

The similarities become like an optical illusion you can’t un-see.

Steve Jobs on Defining the Problem

Defining The Problem

The above image is a screengrab from this behind-the-scenes video of Steve Jobs and the NeXT team building their strategy. This happened in late 1985, so the slide was actually a transparency on an overhead projector.

The products and markets have changed since then, but the need to clearly define the problem your product solves has not. I want to hear the story of a better tomorrow where a customer is succeeding with your product in a new way.

Designing for Mobile

Designing for Mobile (by Craig Villamor)

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.