You know that thing where you get home after a long day and catch yourself some time later staring off into space, pigging out on a bag of Doritos and…? Oh, uhh, no me either. But I heard that happens to some people.

Anyway. I’ve been thinking about that phrase you always see on consumer goods packaging when they go through a redesign. The almost-apologetic and slightly nervous proclamation that even though the thing now looks different, nothing else has changed:

Clearly marketers have learned that consumers don’t like redesigns, so they started using this message in a defensive attempt to soften the blow for people. Even then, it doesn’t always work. Remember when Tropicana reverted to their old packaging because some people called the redesign “ugly” and “stupid”? We should know this by now: people have opinions, and they are going to make a big noise about those opinions.

Yet whenever we go through a website redesign process we appear to develop some amnesia around this topic. We seem surprised when people spew vitriol all over Twitter, and we try to make ourselves feel better by saying that they’ll “get used to it.” Some part of me really wants us to create “Bold new look, same great functionality!” gifs for those kinds of projects, in the spirit of the “Under construction” gifs of yesteryear. But just like in the case of Tropicana, I don’t think that will work.

What’s the alternative? Well, first, we have to realize the biggest problem with big web/app redesigns. It might be the same functionality underneath (or not), but that functionality is often harder to find, and that frustrates users to no end. The good news is that we work on the web, not in packaging. We can do things incrementally! In the words of Cameron Moll, “Good designers redesign, great designers realign”. I’ve also written about this before in The Data-Pixel Approach To Improving User Experience:

The main problem with big redesigns, therefore, is that, even though objectively the UX might have been improved, users are often left confused about what has happened and are unable to find their way. In most cases, making “steady, relentless, incremental progress” on a website (to borrow a phrase of John Gruber) is much more desirable. With this approach, users are pulled gently into a better experience, as opposed to being thrown into the deep end and forced to sink or swim.

Look, I’m not saying this is a perfect analogy. But I spent a lot of time spacing out about this on Friday, so I thought I’d write it down for posterity. What I’m trying to say is, let’s worry less about bold new looks in web design, and instead work on making things taste better.

We’re in the process of hiring UX designers and Product Managers, so I’m currently looking through a lot of resumes. I’m finding the breadth and depth of UX resumes really impressive — there are a ton of great people looking to make a shift at the moment. But on the Product Management side, not so much. I don’t want to believe it’s because most Product Managers suck. I just think there is a big supply/demand issue in this area at the moment.

But not just that, I also think that Product Managers need to write better resumes. Designers have, for the most part, figured out that it’s more about showing than telling. It’s easy to go to someone’s sites and portfolio to get a sense of what they’re about. Product Managers still appear to be stuck in the “Let me tell you how awesome I am” rut, though. This is a generalization, of course, but what I’m mostly seeing right now is resumes that excel at vagueness. It’s not uncommon to see a sentence like “Applied world-class methodologies to create a successful customer-centric product”, or some variation of that. What does that mean?

It’s great to see proof of success, yes — stats about conversion improvements, etc. are extremely useful. But hiring managers need more than that to assess Product Managers. We need to know how you think. We need to know how you approach problems, how you work, what methods you like and don’t like, and why. And for some reason most PMs I speak to seem surprised by those questions and have trouble answering them.

I’ve now gone so far as to send a short list of questions to our HR department. I’ve asked them to forward these questions on to potential candidates, and send their answers to the hiring team along with their resumes. So I wanted to share those questions here in case it’s useful to PMs looking for a new opportunity. This isn’t an exhaustive list, but here are some of the questions Product Managers need to be able to answer at any time of day or night:

• How would you describe your ideal product development process? Please share details including, but not limited to, the following:
  • Roles and responsibilities within the team
  • How to develop a strategy and vision for the product
  • How to decide what to build, and when (include thoughts on different prioritization methods and, in your experience, what works best)
  • Development methodology
• In your experience, what are the most important characteristics of a good Product Manager?
• In your experience, what are the conditions for success that have to exist in an organization for a Product Manager to be successful?

This is one of those classic “there is no wrong answer” situations. The absolute answers matter, but what matters more is the thought process. I want to hire PMs who think about these things. PMs who have an opinion on UCD vs. ACD. On Kano vs. KJ prioritization. On user stories vs. job stories. I want to work with people who read and think and build, and have found a way to balance those different activities effectively.

So, if you’re looking for a Product Management role, communicate those things to the recruiter and/or hiring managers. I’m pretty sure it will get you an interview. Oh, and if you want to move to Portland to help us make better healthcare software, and you have good answers to those questions, let me know!

This is a written version of a talk I gave at Industry Web Conference on April 23rd, 2014. It’s a great conference and you should definitely attend next year.

This is a photo of what many believe is the first wireframe ever created. It’s attributed to Paolo di Dono (aka Paolo Uccello), dating somewhere in the mid 1400s (source):

Back then, wireframes were used to accomplish very specific goals to help with the design of everyday objects (source):

• To view the model from any desired point
• To produce standard and auxiliary views
• To create perspective views more easily
• To analyze distances within the structure
• To check tolerances and interference
• To decrease the number of prototypes required
• To edit the model

Wireframe models are particularly useful in the world of architecture, so it’s no surprise that software used to create CAD models incorporated wireframes as core to the product:

Image source

To clarify things a bit, wireframes were originally used to accomplish two product design goals: to reduce rework, and to speed up delivery. Those are words that will make any designer or developer’s ears perk up. Who doesn’t want that?

However, somewhere along the line we’ve watered down wireframes to something completely different. At worst they’re reverse-engineered artifacts based on completed PhotoShop files once an agency account manager remembers they’re supposed to “do UX” as part of the project they sold. At best they’re hailed as good communication tools — nothing more, nothing less. We’ve managed to reduce a highly useful design tool to something we fight over on Twitter. And it’s not just the humble wireframe that’s in the crosshairs. Personas. PSDs. Debrief presentations. They’re all looked on with the same disdain:

The reality is that there is a lot of truth to the criticism we lavish on “deliverables”. The Lean movement is right about the main reason for getting out of the deliverables business — whatever time we spend documenting stuff is time spent we’re not making stuff, and that’s a problem. It’s much better to create hypotheses, build them quickly, and test them with users to get feedback and iterate. I’m in complete agreement on that approach.

That said, there is a problem with this approach that has started to become more and more bothersome as I went on my own journey to stop making deliverables. The problem is that design is path-dependent. The choices we make early on in a design constrain the choices we can make later on. Ryan Singer sums this up really well in his answer on the Quora thread Should I focus on a good user experience, or push something out quickly?

On the very first iteration the design possibilities are wide open. The designer defines some screens and workflows and then the programmer builds those. On the next iteration, it’s not wide open anymore. The new design has to fit into the existing design, and the new code needs to fit into the existing code. Old code can be changed, but you don’t want to scrap everything. There is a pressure to keep moving with what is already there.

Our early design decisions are like bets whose outcome we will have to live with iteration after iteration. Since that’s the case, there is a strong incentive to be sure about our early bets. In other words, we want to reduce uncertainty on the first iterations.

So the main issue I kept running into as I stripped deliverables out of my design process is: how do I know where to start? How do I make sure I start in a place that isn’t going to limit me so much that I’ll have to start over completely at some point? And not just that, but what about that thing we all want to pretend doesn’t exist but we have to deal with every single day? You know, the S word. Stakeholders. Those people who need to know what’s going on and why, all the time. Without deliverables we’re kind of exposed to the elements on that, with nothing to lean on.

Something’s gotta give, and I think that something is the deliverables we make part of our design and development process. So I started thinking.

I started thinking about Jared Spool’s excellent piece from earlier this year, A Bias For Making, in which he wrote the following:

A bias for making doesn’t mean the team never plans. On the contrary, plans happen fluidly throughout the entire design process. The difference is they are evolving as the team learns from the process of making.

And then I started thinking about Giff Constable’s words in 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.

And as I kept thinking about all this stuff, I started to realize that there are some things that the right deliverables could actually be good at. For example:

• Deliverables could provide a better baseline to start a design from, particularly when it comes to device-agnostic design and development.
• Deliverables could help teams running along smoothly by anchoring everyone on the same vision, and serving as a communication tool to help executive teams understand the execution plan.
• Deliverables could help with building up organizational memory, so that when the inevitable leadership changes happen, everything doesn’t get scrapped to start over.

Of course, the next obvious question is, what are these right deliverables you speak of? If we’re all agreed that flat wireframes and millions of PSDs are against the spirit of Lean, what’s the alternative? How do we solve the problems that “no deliverables” present, and come up with something that helps us create better products (which is the end goal we all have in common)?

There are two kinds of deliverables that I’ve been working on as possible (work-in-progress) solutions to these issues, and in this post I’d like focus on one that clearly needs a better name: Expanded Customer Journey Maps.

Journey maps are visual representations that help summarize research, highlight and prioritize user needs and opportunities, and give teams a common goal to work towards (see Adaptive Path’s excellent introduction at The Anatomy of an Experience Map). A product’s journey map is important because:

• It confirms a common understand of the users’ needs and goals, and the strategy you intend to follow to attend to those needs and goals.
• It is an excellent prioritization tool, since it allows companies to focus on the most important parts of an experience first, without losing sight of the overall picture.
• It is a guiding light for design. Every time a design idea comes along, a quick glance at the journey map helps us figure out if it’s a good idea that will accomplish the chosen strategy.
• It is an excellent conduit for content-first design, which fits in perfectly with responsive design approaches.

There are many different ways to create a customer journey map. It has some common elements, such as a visual representation of customer touchpoints, emotions, and key takeaways throughout their experience with a product. But that’s only useful up to a point, so we’ve started to expand on the concept. In addition to the usual elements, this document also becomes a representation of the information architecture and the product’s content plan, with personas (needs, goals, scenarios) serving as the starting point for everything — the glue that ties it all together.

This new document is a summary of everything we need to know to design the best possible product for users. It has the following elements:

• Unique selling points to keep us focused on what the site needs to communicate at all times. This comes straight from the persona needs and goals.
• Journey stages and model to remind us how the product fits into people’s lives, and what the primary calls to action need to be throughout the site. This section is a visual representation of a customer’s journey from realizing they might have a need for the product, until long after they’ve used it. This helps product managers keep a holistic view of the entire product and how it fits into users’ daily lives.
• Questions that our target personas are likely to ask in each phase of the journey, to focus the type of content we serve on each page. In an e-commerce context, these are questions like, “Can I trust this retailer?” or “When will my stuff arrive?”
• Takeaways and key principles to summarize the unique selling points, journey model, and user questions, and document how they translate into the design decisions and solutions we need to keep in mind throughout the design process.
• Content plan that maps each phase of the journey with the questions our personas will ask during that phase, and what it means for the specific content that needs to go on each page. We get very specific here — nothing gets on the page unless it’s in the content plan. And if we can’t identify a persona that would find the content useful, it doesn’t go on the list.

Below is an example of an expanded journey map. You can click through to see a larger slice of one of the sections.

There are a few things that we found this kind of expanded customer journey map does really well:

• It is completely device-agnostic. It starts with personas and content, and the entire design remains anchored on that.
• Once you get going, design cycles happen faster, because everyone is aligned on the vision and direction.
• During user testing we tend to find fewer usability issues because we already thought through the most common problems that might occur.
• As a team we tend to have better arguments — meaning we don’t fight about whether the button should be blue or yellow, but whether the design accomplished the goals we agreed on.

It’s not a perfect solution, of course. Everything has drawbacks. In the case of expanded journeys, we’ve found the following challenges that we still need to work through:

• There’s no denying it, the initial lead time before design starts is longer. That’s just the way it is, because thinking about a problem takes time. Once the design phase starts we actually make up that time in spades, as mentioned above, but it can still be an awkward time with clients and internal stakeholders if they can’t see “pictures” as quickly as they might want.
• It’s easy to get distracted if you’re a UX nerd. This stuff is so exciting for some people (ok, me) that it’s possible to stand in front of that white board for days if you don’t check yourself. This isn’t about making a nice piece of paper, it’s about making a better product. Give it your best shot, and then move on. Don’t get lost in analysis paralysis.

So where does this leave us? Yes, deliverables can slow us down and result in documentation that no one reads. But the right deliverables anchor teams in a united product vision, they provide early validation for product ideas, and they speed up (the right) making activities. That’s worth the drawbacks for me. Remember, deliverables aren’t bad. Bad deliverables are bad…

This is still a work in progress. I’d love to hear others’ thoughts on this methodology, and if they’ve expanded it in other directions. If you have thoughts or ideas please let me know on Twitter, or write a post and send it to me. I’ll link to it here.

In The Surprisingly Large Cost of Telling Small Lies Rebekah Campbell looks at the problem with lying in the context of entrepreneurship and creating products:

Peter maintains that telling lies is the No. 1 reason entrepreneurs fail. Not because telling lies makes you a bad person but because the act of lying plucks you from the present, preventing you from facing what is really going on in your world. Every time you overreport a metric, underreport a cost, are less than honest with a client or a member of your team, you create a false reality and you start living in it.

And it’s extremely difficult to get out of that reality once you’ve created it.

Steven Sinofsky wrote some excellent advice for product managers in his post Shipping is a Feature: Some Guiding Principles for People Who Build Things. I especially like this part:

A decision means to not do something, and to achieve clarity in your design. The classic way this used to come up (and still does) is the inevitable “make it an option”. You can’t decide should a new mouse wheel scroll or zoom? Should there be conversation view or inbox view? Should you AutoCorrect or not? Go ahead and add it to Preferences or Options.

But really the only correct path is to decide to have the feature or not. Putting in an option to enable it means it doesn’t exist. Putting in an option to disable means you are forever supporting two (then four, then eight) ways of doing something. Over time (or right away) your product has a muddled point of view, and then worse, people come to expect that everything new can also be turned off, changed, or otherwise ignored. While you can always make mistakes and/or change something later, you have to live with combinatorics or a combinatoric mindset forever.

The flip side of this is, of course, that the organization needs to agree that product managers have the autonomy to make these kinds of decisions.

I love this quote from Suzanne Slatcher, who worked at Pixar in the early years. From the really interesting article Building The Next Pixar:

“Business is just an idea, like a movie,” says Slatcher. “What if we did this in this place at this time, in this style of packaging, with this choice of flavors? Would it work? There’s still a back and forth between creative and the audience, and you can’t be like ‘if I build it, they will come.’ No, we’re in a democratic world where everyone has opinions. If you’re making your cartoon and your joke’s not funny, it’s just not funny, it has to go. If people don’t like a flavor, they’re right, we’re not right.”

That last sentence is a key concept in product development as well. If people don’t like our “flavor” of product, they’re right and we’re wrong. We have to fix it, not try to convince them that they don’t “get it”.

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.