John Maeda on The Great Discontent:

I’ve never met anyone who is good at what they do creatively and is super-confident.

Well, that’s a relief. Because I’m not feeling particularly confident right now. He goes on to say this:

If you have audacity and take on a risk, it means you don’t know what you’re getting into; you’re walking through a door, into a dark room, with no idea what’s there. If you have courage, it means that you know exactly what’s behind that door; there’s something dangerous, hard, and it’s going to make you really uncomfortable.

I don’t know if I’m audacious, courageous, or just plain crazy, but in case you were wondering why it’s been so quiet here over the past couple of weeks, it’s because I just moved from Cape Town to Portland, and today started a new job as Director of Product at HealthSparq. I’m excited about the move and the role, but also pretty nervous about the dark room I’m walking into. But I guess that’s what makes life exciting. That not knowing that keeps us pushing to find our own limits so we can break through them.

I expect things to stay a little bit slow on Elezea for another week or so. This week is obviously crazy, next week I’m speaking at Industry Conf, and after that things will hopefully return to a reasonably regular posting schedule. I just felt that I probably owed you guys an update.

Thanks for caring.

In WordPress: How It Came To Be And Where It’s Heading Alex Moss interviews Matt Mullenweg and Mike Little, the two cofounders of WordPress. The whole interview is interesting, but their approach to technical debt caught my eye in particular:

We rewrite or refactor about 10 to 15% of WordPress in most releases, so that we can keep users getting updates and new features quickly, while doing the “ground up rebuild” incrementally in the background, fixing bugs and getting feedback as we go.

This is, in my experience, the best way to handle technical debt: pay down a little bit of it in every release. To steal a slide from my Product Management course, here’s my general rule of thumb (and of course there will be exceptions) for balancing a product roadmap:

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.