Take care of the people you love, and try to make yourself known and understood. Dial it down, work with your hands, keep it quiet, and share what you know.

— Frank Chimero, This One’s for Me

In 16 days our family will walk out of an empty house in Cape Town and get on a plane to Portland, OR. It will be a one-way journey. I’ve been searching for the words to write about it, but I haven’t quite found the right ones. So I guess these ones will have to do.

I started my first blog in 2004. It was hosted on Windows Live Spaces, and it was terrible. I called it Leave The Great Indoors (yes, because of the John Mayer song and we just moved countries and just roll with it ok?). I have no idea what I wrote about back then, but I must have felt that there was something to this writing thing, because a year later I moved it to Blogger (because more features!). It still exists, but please don’t tell anyone.

The writing thing kept growing on me, and a couple of months later I started a UX-focused blog called UX-SA (because User Experience, and I’m from South Africa, and yes it’s a stupid name for a blog). That one also still exists, but again, please don’t tell anyone.

It was only in late 2009 that I got serious about it, bought a domain name (I don’t know what I was thinking — no one can pronounce Elezea), installed WordPress, and got stuck in. I proceeded to go through several identity crises, which included a move from Silicon Valley to Cape Town, 2 kids, and realizing that I’ll never learn how to deal with angry comments so I should probably turn those off.

One day I wrote a post that got mildly popular, and Jim Dalrymple linked to it from The Loop. He also must have subscribed to my RSS feed, because he has linked to the site a few times since then — something I’m still surprised by and incredibly grateful for every time it happens.

Some time after that a guy I’d never met, who lives in Portland, started following me on Twitter. He’s a regular reader of The Loop, and he decided to check out this guy who has the same last name as he does (let’s call him Rudolph, because that’s his name). We started chatting a bit, and when he came to visit his extended family in Cape Town we caught up for coffee. We kept in touch, as like-minded people are prone to do.

Last August my wife and I went to San Diego for a family reunion. I also set up some interviews because we were strongly considering moving there. But we took one look at California and realized we won’t be able to live there again (Cape Town kind of gets you addicted to leafy mountain beauty, and well, California). On a whim I gave Rudolph a call, and asked him if he thinks we should move to Portland. I’d been following him on Instagram for a while, and it looked like a nice place.

So this random guy I met on the Internet went to work and helped us figure out if Portland might be the city for us. A few months later I started looking for jobs there. Since I’d never been to Oregon I took a one-week trip to check it out and speak to some people in person. Of course I stayed with Rudolph and his lovely family.

I talked to several companies in Portland, but the conversations that kept sticking in my mind were the ones I had with HealthSparq, a healthcare transparency company that’s part of Cambia Health Solutions. I never thought I’d work in the healthcare field, but the team’s passion and vision won me over. So on April 13th I’m starting at Healthsparq as a Director of Product. Healthsparq’s president, Scott Decker, wrote a post the other day that’s a pretty good summary of why I decided to join them. From Health Care Transparency: Opening Up the Market:

It’s important that these new transparency tools provide robust information that people want to know in a way they can make actionable. While more and more health care data is being generated and released — from personal tracking devices to government and payer data — the information won’t be useful unless it is understandable and easy to navigate. These new transparency tools should provide as complete a picture as possible of price and quality, from the moment a person begins receiving care for a specific condition to the time when they no longer require treatment.

That’s a tough UX problem, and a vision I can get behind. I’m excited about the move to a new city with new beginnings and new things to explore — and a product I can believe in.

Anyway, I’m telling you the strange story of how this all happened because I’m worried that we don’t always appreciate how cool the internet can be. My decision to start a crappy blog in 2004 eventually led to a bunch of connections with fantastic people who decided to give me a shot (remind me to tell you about the day that Francisco sent me a DM to ask if I’d like to write for Smashing Magazine). This move wouldn’t have happened if I hadn’t met Jim and Rudolph online, and if they weren’t such nice people, and I can’t quite get my brain around how great that is.

We give the internet a lot of crap, and yes, it can be a vile place sometimes. But we’re moving to Portland because of relationships that were started and cemented on the internet, so I’m going to remain in awe of this technology that has the power to help us make each other’s lives so much better.

Giff Constable makes the case for validation and learning in the product development process before you launch something. From You Are Spending 3x-5x More Than You Should:

Agile/lean has helped people debunk the “big upfront design” phase, but far too many replace it with nothing. I agree that waterfall-style, big-upfront-design is a waste of time and money. I do believe that getting into the market with a designer and an engineer and learning is a critical use of time.

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!