A few months ago I wrote about the forces at work when people choose a product. I discussed the Jobs-To-Be-Done concept of Progress-Making Forces, and shared this diagram to illustrate what happens when we try to get people to use our product instead of someone else’s:

In this article I want to discuss this framework in the context of a practical example: WhatsApp vs. Instagram Direct (now both owned by Facebook). I started thinking about this recently after MG Siegler wrote his post Going Against The Grain:

We’re seeing over and over again now that the behemoths can’t simply add a startup’s functionality into their own app as a feature and kill said startup. But it’s equally important to note that if you are able to establish your startup, especially those in app form, it may be hard to get your users to do anything other than what they originally came to do. Especially if the new functionality is against the grain in any way.

So, let’s consider this statement in the context of the Progress-Making Forces, and apply it to Instagram’s decision to add private photo sharing with Instagram Direct. First, let’s talk about existing photo sharing behavior. How do people currently send photos to each other? Facebook used to be the king of photos, but people are increasingly using messaging apps for this instead:

WhatsApp is processing 500 million images per day, compared to 400 million Snapchat (“snaps”) per day, which could include photos or videos. For its part, Facebook processes a comparatively paltry 350 million photos a day.

Enter Instagram Direct, a way for Facebook to try to claim back some of the private photo sharing pie. That’s the new behavior in the context of the the forces diagram. So the big question for Facebook is this: How do you get people to move their private photo sharing from WhatsApp (existing behavior) to Instagram (new behavior)? According to our framework, the progress-making forces need to be stronger than the progress-hindering forces, so let’s look at each force in turn:

• Push of the situation. Is there anything people are not able to do by sending photos through WhatsApp that they wish they could do? It doesn’t seem that way. Some of the biggest advantages of using WhatsApp for photos are that (1) it’s completely private, and (2) it ties into your phone’s camera roll, so you have access to any photo, not just the ones from a particular app.
• Pull of the new idea. Is there anything in Instagram Direct that could entice people away from WhatsApp? Again, it doesn’t look like it. Using Instagram Direct is simply more work than using WhatsApp for photos. If the photo isn’t in Instagram yet you have to import it. You have to apply a filter because that’s what you do in Instagram. Only then can you send it. But then the entire conversation is centered around photos. You still have to use WhatsApp for text messaging. So now you’re communication is fragmented, while it’s all seamlessly integrated in WhatsApp. There’s no pull here.
• Allegiance to current behavior. How strongly are people attached to their WhatsApp experience? Extremely. The benefits of having all conversations and photos centrally located in WhatsApp can’t be overstated. You’re not just sending photos, you’re talking about life. It becomes a timeline of your relationships, and everything is there.
• Anxiety of new solution. How worried are people that the shift would ruin their experience? Well, it seems there would be quite a bit of anxiety involved in moving to a product that doesn’t support the functionality you’re used to, and sits within a walled garden.

This analysis clearly shows that while the progress-making forces for moving people to Instagram Direct are relatively weak, the progress-hindering forces are extremely strong. This keeps people glued to WhatsApp, and it explains Instagram Direct’s apparent failure.

So what happened here? I think Facebook realized that they won’t be able to change people’s existing photo-sharing behavior. And that’s why they bought WhatsApp.

Peter Seibel discusses data-driven design at Etsy in his post Building websites with science. After going over the dangers of relying solely on A/B testing for product decisions, he concludes:

Ultimately the goal is to make great products. Great ideas from designers are a necessary ingredient. And A/B testing can definitely improve products. But best is to use both: establish a loop between good design ideas leading to good experiments leading to knowledge about the product leading to even better design ideas. And then allow designers the latitude to occasionally try things that can’t yet be justified by science or even things that my go against current “scientific” dogma.

This echoes Julie Zhuo’s thoughts in The Agony and Ecstasy of Building with Data:

You can’t A/B test your way into big, bold new strategies. Something like the iPhone is impossible to A/B test. If you had asked people or invited them to come into the lab to try some stuff out, they would have preferred a physical keyboard to a virtual one. If you had them use an early prototype of the touch screen where not every gesture registered perfectly, it would have felt bad and tested poorly. […]

Data and A/B test are valuable allies, and they help us understand and grow and optimize, but they’re not a replacement for clear-headed, strong decision-making. Don’t become dependent on their allure. Sometimes, a little instinct goes a long way.

This all relates back to the difference between variation (trying out different ideas) and iteration (small changes to improve an existing idea). A/B testing is great for iteration, but not for variation. For variation we need our brains, and lots of paper and pencils.

Cap Watkins in Just Ship*:

We work in a world now where fast isn’t good enough. Where quantity is fairly regularly getting edged out by quality. You shipped twelve just-good-enough things this year? You’re about to get smoked by folks who shipped three of those things thoughtfully and holistically. Where you cut corners on twelve projects to get them out the door, someone else crafted three focused experiences and left themselves little-to-no design or technical debt.

This also describes why arbitrary release dates are poison to good quality products. It forces teams to cut corners to hit a date, which puts them in a more vulnerable position than if they just took the time to do things right.

Also:

Why do we never have time to do it right, but always have time to do it over?

— Alan Skorkin (@skorks) April 10, 2013

Jeff Atwood wrote a glorious rant about the proliferation of unnecessary mobile apps called App-pocalypse Now1:

The more apps out there, the more the app stores are clogged with mediocre junk, the more the overall noise level keeps going up, which leads directly to this profligate nagging. Companies keep asking how can we get people to find and install our amazing app instead of the one question they really should have asked.

Why the hell are we building an app in the first place?

He makes some other really great points about the current state of the app ecosystem as well.

---

1. I really struggle with puns. I don’t like them. So publishing this title is a big step forward in my ongoing therapy. ↩

MG Siegler in Going Against The Grain:

We’re seeing over and over again now that the behemoths can’t simply add a startup’s funtionality into their own app as a feature and kill said startup. But it’s equally important to note that if you are able to establish your startup, especially those in apps form, it may be hard to get your users to do anything other than what they originally came to do. Especially if the new funtionality is against the grain in any way.

This comes back to understanding what job users hire your product to do for them, and realizing that it’s very difficult to convince them to use the product for a different job.

Jared Spool in Design is the Rendering of Intent:

Over the last year, we’ve started explaining design as “the rendering of intent.” The designer imagines an outcome and puts forth activities to make that outcome real.

He believes this is one of the reasons why, even though they’re both government sites, We the People is so much better than the enrollment system for Global Entry:

There’s no technical reason why the We The People team had to end up with the design they did. It could’ve been frustrating and hard-to-understand, just like the Global Entry site or many other government web sites. The only reason either team ended up with these sites is because they came to their designs with different intentions. […]

Many of our design deliverables, such as wireframes, prototypes, and style guides, are as much about getting agreement on what we intend as they are to move our intentions closer to done. But the deliverables themselves do not produce the designs. It’s having all the people on the team, from the product managers through the developers, sharing the same intention.

We need to look at our design process as a way to come to a single intention as much as it is to make that intention real in the world. And it’s with the lens of this new definition that we can see we still have much work to do before every design will be a great one.

User intent is not a new design concept, but I like how Spool extends that to deliverables. Most deliverables are part of an essential process to get everyone to agree on the intent of the product, as well as the user intents that the product aim to deliver. Through this lens the right deliverables are closely related to Jobs to be Done, and therefore still very relevant and useful.

James Stout explains how Responsive Design won’t fix your usability issues for you. If your site is bad before the redesign, those problems won’t just magically go away once you’ve gone responsive. It’s a good article, and I especially like this bit:

But in the face of all this great technology, it’s more important than ever to avoid the “features for features’ sake” pitfall. Maintain that ever-present purpose and goal and be deterministic concerning whether these technologies help drive that goal, or whether they’re being included simply because they’re new. Use only those features you need and make them truly spectacular when you do.

The mobile revolution is nothing new, yet the battle to bring it about rages on. Understand that success on the web is not defined by the tools in your arsenal, which any web-MacGyver can use, but by the strategy you employ, including the very manner in which you approach the field.

It reminds me of one of my favorite Product Management quotes, from Barbara Nelson’s Who Needs Product Management?:

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

Des Traynor’s Product Strategy Means Saying No is also a great article on the topic of product focus and market needs:

Identifying and eliminating the bad ideas is the easy bit. Real product decisions aren’t easy. They require you to look at a proposal and say “This is a really great idea, I can see why our customers would like it. Well done. But we’re not going to build it. Instead, here’s what we’re doing.”

And since I haven’t linked to Michael Wolfe’s answer to Why is Dropbox more popular than other programs with similar functionality? yet this year, I might as well do it now and get it over with:

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

I’m excited to be part of Industry Web Conference in April this year, alongside some people I’ve admired for a long time. I’m going to be talking about a thing that’s fallen out of fashion a little bit over the past year or so: Deliverables. Yep — the business we’re supposed to be getting out of. So I’m a bit nervous about the talk, but I hope people will give it a chance.

The talk is called Getting back into the (right) deliverables business, and here’s a little more about it:

I feel a little bad for the static wireframe. It’s had a bad year. In fact, UX deliverables in general have had a bad couple of years. There’s a growing skepticism about the value of Personas and other traditional UX artefacts, as well as an onslaught of “get out of the deliverables business” refrains from Lean methodologies.

All of this led me to lots of introspection about deliverables, and if it’s actually possible to create deliverables that are useful to help create better products.

In this talk I’ll tell our story. How we stripped down all our deliverables to almost nothing, and then started building it all up again slowly by asking ourselves, “What is absolutely necessary for us to do a great job?” I’ll discuss some of the deliverables we’ve since created (such as Expanded Journey Maps and Content Slice Diagrams), how they’re useful to us, and how you might be able to use them in your design process as well.

We’ve come to realise that not all UX deliverables are bad. Only bad deliverables are bad.

I’m going all in on this — the day before the conference I’m also doing a full-day workshop called Using Customer Journey Maps for Effective Content-First Design. This will be a very practical day on what has become an essential deliverable for us:

More than just a journey with touchpoints, emotions, takeaways, etc., it’s also a representation of the Information Architecture and the content plan, with Personas (needs, goals, scenarios) serving as the starting point for everything — sort of like the glue that ties it all together.

You can think of this as the UX Strategy document. It incorporates Persona-based user needs and business goals with site structure and content planning in a way that really works. It also places content at the centre of the design process, which makes it easier to follow mobile first and responsive design strategies.

In this workshop we’ll discuss the value of this document and then go through a practical exercise to create an Expanded Customer User Map so you can apply it in your roles immediately.

So anyway, I’m really looking forward to it. And here’s the special bit. If you use the discount code rian, you can get conference tickets and/or workshop tickets for £40 off. That’s a pretty substantial discount. You can read more about the conference here, and register here. I hope to see you in Newcastle upon Tyne in April!

In Product Kyle Neath asks:

We are focused on likes, app opens, hours spent, pageviews, and company valuations — but do these translate to a better future? Are we using ads to provide for a connected humanity, or conning people into conspicuous consumption? It’s hard to judge. I do know that it just feels right when you build a good product. […]

That’s really the core of it: how can we create financially sustainable products that bring people joy and make the world a better place?

I think this is where side projects fit in so well. It’s our time to dream quietly about what could be, and take small steps towards making that dream a reality. Which reminds me, I just bought Rachel Andrew’s The Profitable Side Project Handbook. It’s getting some good reviews, so I’m excited to dig into it.

Vijay Sundaram takes the concept of technical debt and applies it to User Experience Design:

You know you’re a subprime borrower when your team decides to “clean this up next release”. But the next release has a backlog of critical bug fixes, must-have feature requests, and of course plenty of new design shortcuts that emerge in the process. What’s more, the usage data for the last release is showing great engagement and no one has complained yet about the shortcuts you took. Fixing those can’t possibly be a priority right now. Before long, the team is grafting one design shortcut onto another, and the only way to unwind them is a wholesale reboot.

The article made me think of Henrik Kniberg’s excellent Good and Bad Technical Debt (and how TDD helps), in which he explains the concepts of a “good mess” and the “technical debt ceiling”:

A fresh mess is not a problem. It’s the old mess that bites you. […]

If you are coding up a new feature, there are lots of different ways to do it. Somewhere there is probably a very simple elegant solution, but it’s really hard to figure it out upfront. It’s easier to experiment, play around, try some different approaches to the problem and see how they work. […]

The problem is, just like in the kitchen, we often forget to clean up before moving on. And that’s how technical debt goes bad. All that “temporary” experimental code, duplicated code, lack of test coverage — all that stuff will really slow you down later when you build the next feature.

So regardless of your reason for accumulating short-term debt, make sure you actually do pay it off quickly.

I’ve been wondering how this applies to UX debt. Is it ok to take some design shortcuts, knowing that you’ll come back later and fix it (up to a “UX debt ceiling”)? My gut feeling is to say no, because design is so path-dependent. Your early choices constrain your later design choices, so if you make the wrong choice it can really hurt down the line. For example, if you skip user research in the beginning of the project, you’re highly likely to make the wrong choice about what to build, which isn’t something you can fix easily later on.

The solution is to have shorter UX (and development) cycles, which is becoming commonplace anyway with the rise of the Lean movement. I’m reminded of IDEO Design Director David Aycan’s 2010 article in HBR, Don’t Let the Minimum Win Over the Viable, in which he explains the importance of taking small steps so that it’s easier to correct course when you realise you’re on the wrong track:

Sketching or mocking up experiential prototypes and then testing them with consumers or potential partners, while also explicitly jotting down your operating and business assumptions and using them to discuss the business with industry experts, allows you both to pick a promising route to invest in the development sprint and to pivot with confidence. For example, by prototyping multiple consumer experiences and business models before investing in an initial MVP, GoGo was able to launch an airline WiFi and in-flight service experience that combined the best of multiple alternative services that might be offered in flight. One might think of this approach as testing multiple MVPs in parallel.

Creating multiple options in tandem creates more confidence in the core variables, which in turn means that pivots may be less drastic or disruptive later on. This approach can be applied beyond product features to business models and operating approaches as well.

He uses this sketch to illustrate the approach:

This makes a lot of sense in the context of UX and technical debt as well. A pragmatic approach to dealing with software debt seems to be something like this:

1. Create different possible paths (variation)
2. Pick a direction and work towards it (iteration)
3. Get feedback, address debt and other issues, correct course if necessary
4. Repeat cycle

The trick is to be ok with the early messes, but not let them deteriorate so much that you’re unable to clean things up when you finally decide it’s time. Remember the broken windows theory: “maintaining and monitoring urban software environments in a well-ordered condition may stop further vandalism neglegence and escalation into more serious crime technical issues.”