Looking for a word

Found this great quote by Steve Jobs:

“Look at the design of a lot of consumer products — they’re really complicated surfaces. We tried to make something much more holistic and simple. When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions. Most people just don’t put in the time or energy to get there. We believe that customers are smart, and want objects which are well thought through.”

I’ve also heard this idea described as “living with the problem”. The key to it is that it takes time and sustained focus on a problem to really understand it…to see it from different angles and to grok it fully. For me this becomes easier when you prototype and test often…when you watch people use your product over and over again enough so that you see the usage patterns that aren’t obvious. This can be done most readily by talking with and observing your users use your product every single day…but of course that’s easier said than done.

I think we need a word for this…this sustained exposure to a problem when you live with it long enough that you get through the obvious assumptions…the first pass solutions that most people would come up with. You then get to the more subtle solutions, the elegant ones that aren’t visible at first.

The Why and How of UX

In order to align a company around delivering great experiences, Peter Merholz says, “there are (at least) six components that need to be aligned throughout the organization”:

The Why and The How of Organizations that Deliver Great Experiences

They are: value, vision, goals, incentives, processes and capabilities. My experience agrees with this…you need both vision at the top end and incentives at the bottom end to set the right goals and drive the right processes (and hire for the right capabilities).

Customer development notes

A great little list by Cindy Alvarez: » 10 Things I’ve Learned About Customer Development (2014).

The overriding lesson in this list (and in customer research in general) is that you can’t simply trust what people say during an interview…because people being interviewed are biased to please you (or not look stupid). Instead, you must verify with previous behavior…make sure that people are indeed already doing what they say they would do. If someone says they would spend money for your product, for example, you should verify that they are indeed spending money on a competing solution. If they are, it doesn’t mean that they would buy your product, but it does mean that they’re the type of person you should be talking to. If they aren’t then you can basically throw out their answer because they aren’t in your target audience.

In general, future behavior is predicted by past behavior…so tread carefully. People say all sorts of pleasing things in interviews and it’s incredibly easy to take their initial, positive answer as the truth. In most cases digging a little deeper will be much more insightful.

There is no later for your customers

When building something is expensive, like a physical object, prototyping early and often becomes the obvious way to improve the product cheaply. If you’re designing a new chair, for example, it makes sense to prototype, test, and prototype again before sending the final design off to the manufacturer. The workflow of physical products is naturally separated into design and manufacturing. “Sending it off to manufacturing” means that the design is done and can’t be changed. Same with “sending it off to the printer”.

Creating software is entirely different. We can change the product at any time, redeploy, and our users will be using the new software in a very short amount of time. I think this ease-of-change has had many effects…one very important one being that we risk losing the design discipline of physical and printed goods. When sending something off to the printer is a final action it forces the designer to test, verify, and test again before taking the leap. The discipline and attention to detail is necessarily greater because you know you can’t change anything.

The ability to change anything at any time is an amazing luxury. We are spoiled rotten as software creators that we can change the software our customers use within minutes if necessary. But I fear that this ability has eroded an acute attention to detail and a discipline of refinement that exists in other production environments. If we can change things at any time then let’s just launch this as-is and improve it later. It is remarkable how easy it is to justify any release with these simple words: “we’ll improve it later”.

There is no later for your customers. The only thing that matters is what they’re using right now. They don’t give a shit about your roadmap, your brilliant feature pipeline, or your vision of a better future. They’re trying to get work done right now and they only know what you’ve already delivered. So build a discipline around your launches, knowing that your temporary, let’s get this out quickly and iterate later release is the current reality for your customers. Build up your attention to detail and force yourself to treat every launch like it is your final launch. Imagine that you’ll never be able to deploy something after this…have you done your best work?

Faster design research

As software becomes more embedded in our everyday lives customer research becomes more important…we need to really understand the problem we’re solving before we can build a great solution for it. Since design and development processes are getting faster every day it makes sense that research needs to get faster too…but research tends to conjure up images of the opposite: long hours slogging through lots of data.

Michael Margolis of Google Ventures is the fastest/most efficient researcher I’ve ever worked with. We’ve worked with him several times at HubSpot and it’s amazing how quickly he can get the right information to take the next step in the design process. He’s put together a short but sweet list of ways to speed up your research. These points are deceptively simple and valuable.

Google Ventures On 8 Shortcuts For Better, Faster Design Research.

Focusing on product

From this interview with Jonathan Ive on Apple’s design process:

“One of the values of things I learned absolutely directly from Steve was the whole issue of focus. What are we focusing on: focus on product. I wish I could do a better job in communicating this truth here, which is when you really are focused on the product, that’s not a platitude. When that truly is your reason for coming into the studio, is just to try to make the very best product you can, when that is exclusive of everything else, it’s remarkable how insignificant or unimportant a lot of other stuff becomes.”

The hidden costs of switching

A good reminder from Tomasz Tunguz: The Hidden Costs Of The Switching Products In The Consumer Web

“In most of the consumer web, I’ve come to believe switching costs are significantly greater than I ever suspected…switching from one product to another requires effort: the time to learn new software and build new behaviors. This is why so many US businesses still use Excel for their book keeping and Word for everything else. No time investment is required to keep the business going.”

You have to know who your real competitors are. Word and Excel are flexible tools that everyone is already using…so using them is just easier than switching to something new.

Consider this: if switching was easy we would do it all the time since there would be no penalty. Here are some switching costs that may or may not be apparent:

  • Price – Price is merely the most visible and tangible cost of switching.
  • Time – How much time does it take to switch? In Tom’s case, and I’ve experienced this myself, just moving gigabytes of files around is a non-trivial task these days. I tried to back up all my image files to Dropbox recently and failed.
  • Workflow – How does switching change the way you work? Do you have to change your workflow to incorporate the new product? Ideally it makes your workflow easier but often it just makes it different.
  • Team – How does switching change your interactions with others? Do others rely on the same product as you? Do you use the product together? When you use something as a team the switching costs become much higher because it means multiple people must switch at once.
  • Social – Increasingly social changes are part of switching costs. As social interactions become embedded within products, switching costs will include changes in social interaction. Are your friends using the new thing? Are there social signals in switching over? Etc. Probably a bigger piece of the pie than we realize.

When designing products, its much better to be completely aware of the real switching costs of your product. In many cases we focus on the obvious ones and miss the hidden ones. I’ve also found that people don’t always report on these hidden costs…they point to your product deficiencies instead. They’ll say “I’m not buying your product because it doesn’t have X feature” when that’s not really the reason why. The real reason is deep-seated and has more to do with costs like Team and Social instead of some missing feature. Missing features is often a bogey…people say all the time that they’re not switching because of a missing feature and that’s just an excuse.

As usual…look at real behavior in addition to doing interviews. Watch what people return to over and over instead of switching to your product. If they’re continuing to hack something together in Excel instead of using your product then you’ve got your work cut out for you…

Changing the model for restaurant visits

A great read on changing from reservations to ticket sales for restaurants by Nick Kokonas, partner at the restaurant Alinea in Chicago: Tickets for Restaurants. This is really about product design…designing the product experience around attending a restaurant. What I like about this is that Nick has touched not only on the obvious improvements in efficiency (like drastically reducing telephone calls) but also on things like the social implications of purchasing a ticket vs. making a reservation. Those two activities do the same thing in the end but are very different conceptually…the way we think about them is different.

Nick mentions several positive outcomes from the change to ticketing. The first one, creating transparency of process for customers, is all about following a basic tenet of design: keep the user in control. When customers can clearly see and choose the table they’re getting at the time specified, and don’t have to deal with slow tables or overbooked restaurants, their trust in the restaurant naturally increases.

Another positive outcome is one that is a larger issue with SaaS in general: their software creates a direct connection between restaurant and patron. I think this is an incredibly important issue for anybody doing product design because it shows the weakness of using 3rd party software solutions that don’t give you access to actual customers. In my opinion if you’re doing business without a direct connection to your customers you are in a very weak spot…consider all the book publishers who have no idea who their readers are. There is no way for them to create a relationship with their readers if Amazon is the one who owns the transaction. Same with restaurants. If OpenTable owns the relationship, the restaurant suffers because they can’t provide as personal a service. This might not be apparent most of the time, but long term I think a lot of software will come back in-house for this very reason.

Andy Baio on selling out

Great read by Andy Baio on the history and future of Upcoming.org: Diary of a Corporate Sellout. For those of you who don’t know what Upcoming was, it was an awesome events website where you could manage the events you wanted to go to (before those types of sites were popular) that Andy created and then sold to Yahoo in 2005. Andy’s story is an important one that anybody building a product should read. In particular, Andy talks about not realizing what it meant to sell a website around which a community had formed:

“If you start a social startup and give up ownership, whether through significant investment or an acquisition, you’re putting a community at risk. It’s not just “data.” It’s the collective effort and history of everyone that breathed life into the thing you made. There’s a huge amount of trust there, and we have every right to be angry when the services we use disappear. They tie to our identity, they forge new friendships, and they hold our collective history.

In the case of Upcoming, it was a decade of memories and experiences from real people. It was my responsibility not to fuck it up. People trusted me with those memories, and now they’re gone. It’s the only time in my life that I felt like a sellout.”

Great read…here’s hoping Upcoming returns better than ever.

Browse Archives