Menu

Design wants more from us than just solving problems

Matthew Butterick recently did a TYPO Talk in Berlin that completely blew me away. In Reversing the Tide of Declining Expectations he discusses how we have come to expect way too little from design, with the consequence that most design on the web is complete crap:

And that’s really what I mean tonight by declining expectations. This idea of what happens when we defer to technology, instead of standing on its shoulders. What happens when we choose convenience over quality. Eventually, w’re going to forget what quality was like.

One of the most interesting parts in Matthew’s talk is where he challenges the conventional wisdom that design is about solving problems. He believes that “solving problems is the lowest form of design” — here’s why:

Because what does design want from us, as designers? Does it only want a solved problem? I think it wants more. I think it wants us to take these items that are sort of mundane or boring on their own—like an annual report, or a website shopping cart, or a business card—and it wants us to fill them up. Fill them with ideas, and emotions, and humor, and warmth. Really everything that’s in our hearts and minds. Design wants us to invest these items with our humanity. And the problem that we’re solving—that’s really just the context where that happens.

I don’t want to quote from the talk too much, because you really have to experience the whole thing — it is such a great reminder to have the courage to create better things.

You can watch the video or read the transcript.

(transcript link via @jbrewer)

Apple: it’s not secrecy, it’s theatre

Michael Lopp discusses Apple’s famous secrecy in the context of the “One More Thing” keynote moments during the Steve Jobs era. As usual, he nails it:

The best stories, the ones we love, have a surprise ending. Since Steve returned to Apple, an essential part of the keynote was the anticipation of the unexpected, and that means aggressive and invasive secrecy. Not because they don’t want you to know, but because they want to tell you a great story.

His point is that “it’s not secrecy, it’s theatre.” Great article.

Apple’s infiltration strategy for the enterprise market

Michael Mulvey points out an interesting distinction between Microsoft and Apple in Very Soft, his response to the news of Microsoft’s first ever quarterly loss:

The thing is, Microsoft has never been a consumer-focused company to begin with. Windows was designed for businesses, not people. Microsoft got in good early in the enterprise market in the 80’s and 90’s and that trickled down to peoples’ home computers. “I have Windows at the office, I might as well get it for home.” That left Apple out in the cold until Steve Jobs came back in 1998.

Contrast that with:

Windows PC spread from the office to the home. In the past 10 years we’ve seen the opposite: Apple products are going from the home to the office.

This is true. As BYOD (Bring Your Own Device) policies become more prevalent, corporate IT departments are finding that many of those devices are iPhones and iPads, and they just have to find a way to deal with that. It goes even further, because these devices are “gateway drugs” that end in employees dumping Windows PCs in favor of Macs (see How the Editor of Windows Magazine Became an Apple Fanboy for a good example). And before you know it you have a groundswell revolt against Microsoft Office for Mac, and a loud push to switch everything to iWork and Google Docs.

It’s a difficult situation for Microsoft, because the shift is mostly driven by masses of individual contributors — not executives. And it’s a situation that Windows 8 is not guaranteed to fix.

The real reason we’re upset about Sparrow’s acquisition

When the news hit that Sparrow has been acquired by Google, you could almost hear the collective sigh from those who use and love this wonderful iOS and Mac OS X email client. Many people (myself included) took to Twitter to voice our disappointment with this move, especially about the fact there there will be no additional development on the app:

We will continue to make available our existing products, and we will provide support and critical updates to our users. However, as w’ll be busy with new projects at Google, we do not plan to release new features for the Sparrow apps.

The response from many others was that we should just get over ourselves:

Matt is right, of course — Sparrow doesn’t owe us anything. The Sparrow team did everything right: they had a great idea, they worked hard on it, and they executed well. That’s why Sparrow is a great app that serves a real need, and why it’s so successful. This is how software development should work: make a great product, and sell it to people for money. The Sparrow team deserves enormous credit for doing that.

But the issue is not that we think Sparrow “sold out.” I don’t think any of us would have turned down Google’s offer if we were in their shoes. The Sparrow team deserve their success, and it’s their software — they can do with it whatever they want. It’s also a great strategic move by Google. If the Sparrow team end up making Gmail better, Google wins. If they don’t — well, at least they’ve eliminated a competitor, and they still win.

We need to reframe this argument. The real issue is much deeper than this specific acquisition. The real issue is the sudden vulnerability we feel now that one of our theories about independent app development has failed.

You see, for a long time we’ve chanted this refrain wherever we could: If you’re not paying for it, you’re not the customer; you’re the product being sold. We point to Facebook and Delicious and ad-supported sites and lament the fact that we’re all just a set of eyeballs being sold to advertisers. So we came up with a solution. We decided that we don’t want to be free users any more. We decided that we want to pay independent developers directly so that they can have sustainable businesses and happy lives.

The philosophy is perfectly summed up in Don’t Be A Free User, a great post on the Pinboard blog:

What if a little site you love doesn’t have a business model? Yell at the developers! Explain that you are tired of good projects folding and are willing to pay cash American dollar to prevent that from happening. It doesn’t take prohibitive per-user revenue to put a project in the black. It just requires a number greater than zero. [“¦]

So stop getting caught off guard when your favorite project sells out! “They were getting so popular, why did they have to shut it down?” Because it’s hard to resist a big payday when you are rapidly heading into debt. And because it’s culturally acceptable to leave your user base high and dry if you get a good offer, citing self-inflicted financial hardship.

This is why I am a paid subscriber to services like Pinboard and Instapaper. It’s also why I paid for the both the Mac OS X and iOS versions of Sparrow. I believe in this philosophy. I believe we should pay people for the things they make, so that they can make it even more awesome.

But with Sparrow’s acquisition the cracks in the philosophy starts to appear. Marco Arment (creator of Instapaper) posted his response to the deal in Talent acquisitions:

If you want to keep the software and services around that you enjoy, do what you can to make their businesses successful enough that it’s more attractive to keep running them than to be hired by a big tech company.

But… that’s what I did. I paid full price for every version of the Sparrow app I could find. I told everyone who would listen to buy it. I couldn’t have given them more money even if I wanted to. So, as a customer, what more could I have done to keep them running independently?

This is the core of the disappointment that many of us feel with the Sparrow acquisition. It’s not about the $15 or less we spent on the apps. It’s not about the team’s well-deserved payout. It’s about the loss of faith in a philosophy that we thought was a sustainable way to ensure a healthy future for independent software development, where most innovation happens.

Agile UX in practice: some concerns

Jon Kolko’s Iteration and Variation is a great article on some of the dangers of iterative design, and how to avoid them. Jon’s main point is that iteration solidifies ideas:

Once this broad stroke has been created (drawn, wireframed, coded, etc), further iterations assume the basic framework as fact. The initial iteration acts as a constraint, and becomes rigid: I’ll refine details and extremities, review and change aspects of the idea, but the idea itself has come to life. […] Each further iteration serves to solidify details, and they become taken for granted: they become facts.

One way to avoid getting stuck on the wrong path is through variation:

Variation is a way of adding a sense of objectivity to design exploration. Variation is an exploration of alternatives. […] Where an iteration moves an idea forward (or backwards), a variation moves an idea left or right, and is not productive in a typical engineering sense: the expectation is that all of the variations (except one) will be rejected. But variations act as provocations for what-if scenarios.

My immediate thought was that even though this approach sounds great, it just won’t fly in most software development processes — especially if the process involves Agile methodologies. Today, Joshua Porter got to the core of why UX and Agile are often difficult to integrate in Is design building interfaces or solving problems?:

But if you view design as “problem solving” then all bets are off. In this case it may take an hour or a week to figure out a solution to a design problem — It depends on the problem and the tenacity of the designer. This makes the initial design phase more unpredictable because your first decent guess is almost always wrong or inelegant (as usability testing often shows). And this makes it more difficult to schedule — and it’s why design doesn’t fit into fixed-time sprints very well.

And that’s the thing. Problem solving involves not just iteration, but also lots of variation. This often requires time to get it wrong a few times, which doesn’t fit comfortably with the concept of release dates. See, the problem with integrating Agile and UX is not that designers want to hang on to “slow and heavy documents,” “big upfront design”, or whatever you want to call it. The problem is that each iteration further solidifies the chosen path, and there is no time to stop and ask if you’re going in the right direction.

This is, of course, where Lean UX comes in:

We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process. While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building

My biggest concern about this, from a practical point of view, is if it allows for enough leeway to test/research different variations, or if it just streamlines the iteration process to get you to the local maximum faster. I don’t know the answer to that, but all I can say is that I’m glad I’m not the only one struggling with these issues.

Maybe we’ll survive technology after all

Brian Frank responds to That Newsweek Article that everyone’s talking about this week in Three Things I Believe About Technology:

Some critics write as if people are helpless automatons who’ll play Angry Birds all day, mindlessly clawing away like beetles turned on our backs unless a clever journalist or wise English professor comes along to flip us around and peddle us in the right direction.

That’s my favorite line, but read the whole thing — it’s an interesting post on some of the larger technology trends we’re currently experiencing.

The value of experiences “around the edges of Twitter”

Andre Torrez wrote a great piece about how his online habits are starting to change. From We met on the Internet:

I’ve been posting about this a bit, but I think my time off pushed me even further along to where I was going. I won’t say “off Twitter”, but I feel like focusing more on things around the edges of Twitter.

And maybe I am just looking for examples””seeing patterns where there are none””but a few things have appeared that makes me feel like other people are feeling the same way.

He goes on to cite some examples of this pattern — Mike Monteiro’s Evening Edition, Dave Pell’s excellent NextDraft, and Dustin Curtis’s Svbtle network.

I’ve also recently found myself yearning for these kinds of off-Twitter experiences that are more substantial, without closing the door on Twitter completely. Now I finally have a phrase for that, thanks to Andre: they’re things around the edges of Twitter.

I often wish I could move all my link-sharing off Twitter and onto this site, but I know that’s not really possible, because the readership isn’t quite there yet. But I much prefer not just tweeting a link, but also adding some thoughts, or even just trying to set the context so people can decide if it’s a link they would be interested in, or not. That’s an “around the edges” experience, since Twitter would still remain central to my workflow, but it wouldn’t be the main activity. Maybe one day I’ll get to do that.

Anyway, that’s quite a tangent. Please read Andre’s excellent post, and think about what that means for you. Does Twitter still add the value to your day that it used to? Bitly did some research recently and found that the average half-life of a link on Twitter is 2.8 hours. After that, it’s pretty much lost forever. Is that ok with you, or are you also starting to cherish the slower, more deliberate communities where you’re allowed to pause and take a breath before moving on to the next thing?

(link via @Mike_FTW)

The dangerous gap between those who make software, and those who use it

The gap between the technical skills required to use the software we make, and what the majority of people are actually capable of, is widening at an alarming rate. Not only that, but we often appear to not even like the people we design and develop for. We champion empathy as a core tenet of user experience design, yet we are mighty quick to point out how bad our moms are at “computers”, and how we hate going home for the holidays because we end up spending all our time on family tech support.

I worry that technology is advancing so quickly that it’s no longer able to ground our thinking in a bit of reality. Some might see this as a good thing, but I don’t. Unless we make a conscious effort to get back into the minds of our users — and not chuckle at what we find when we peek in there — we’re going to run away with the web and leave most of the world standing around in bewilderment, wondering what just happened.

Don’t believe me that this is a thing? Ok, here are some examples. First, CNET’s Greg Sandoval describes the downfall of Netflix in his must-read article Netflix’s lost year: The inside story of the price-hike train wreck. It’s long, so it’s easy to skip over this sentence that perfectly sums up why things went so wrong for Netflix:

But even visionaries can misread their customers when they are blinded by their past success.

CEO Reed Hastings thought he had his customers figured out, but he didn’t. At all.

The second example is Digg, which, of course, made headlines last week because they were sold to Betaworks for $500,000 after once being valued at more than $160 million. From Kevin Rose: Digg Failed Because ‘Social Media Grew Up’:

Among the missteps: Digg botched its re-launch in the summer of 2010, and, more importantly, he said the company was slow to respond to the criticism. ‘We were desperately trying to figure out how to get traffic back,’ he said. ‘A bunch of the community had already revolted by the time we fixed it.’

Once again, they thought they knew their customers, and once again, they didn’t.

For the last example we’ll go even further down the technical totem pole, lest we forget what goes on in the bottom half of the Internet. In 2010 ReadWriteReb wrote an article about Facebook Connect and AOL Instant Messenger called Facebook Wants To Be Your One True Login. But their SEO was so good that if you went to Google and typed in “Facebook login”, that article would be the first result. It wasn’t long before they started receiving comments like this:

Is this Facebook?

That’s right — people thought that they were on Facebook, and that the “new design” had inexplicably taken away the ability to log in. Things got so bad that they had to put up this message in the middle of the article, which is still there today:

No, it isn't

The editors of ReadWriteWeb made one more mistake, though. They assumed that people know what a browser is. Watch this:

You may be asking yourself, “How do these people survive on the Internet? How do they get anything done online?” Well, we’d better believe it — they’re here, walking among us in plain sight. One can argue that things have gotten even worse since that article and video came out. Matthew Berk recently did an analysis of 1.3 Billion URLs and found that 22% of Web pages contain Facebook URLs. Google used to equal Browser for most people. Now Facebook is becoming the browser — it is people’s viewport to the Web.

And what are we doing about this? Well, mostly nothing, because we can’t be bothered to notice. We’re too busy arguing about Twitter’s API, and whether it’s worth reviewing a tablet that doesn’t exist yet. Speaking of the Surface, let’s not forget Greg Cox’s point about the people who are likely to buy it, which serves as another example for the point I’m trying to make:

Ha ha, we scoff. Who wants to do Microsoft Office on a tablet? Office is boring. And tablets have a completely different use case to laptops. Who would want one to run full Windows?

Answer: Lots of people. People with different priorities, working different jobs, living in different countries. People we don’t quite understand.

The rabbit hole just doesn’t end, no matter how deep you go. We haven’t even talked about YouTube comments or Clients From Hell. But I’ll stop here, and just say this: the landscape we create software for is scary. It’s terribly comfortable over here on Twitter, but how can we design software and applications for people we don’t hang out with?

It seems like such a simple problem to solve, but I’m not seeing much evidence that talking to customers is a widespread thing among startups and even many established companies. We love talking about User Experience Design in the abstract — especially if it means we can argue about whether it exists or not.

But you know who are the real heroes of UX (you know, if it actually exists)? The ethnographers. The user researchers (who had to change their name from “usability engineers” because definitions blah blah blah). The real heroes are the people who spend their days understanding user needs, and fighting with all their might to get people to make things that solve real needs, not things that floor us with their beauty and radiance and lack of utility. Douwe Osinga’s description of Google Wave comes to mind:

Wave started with some fairly easy to understand ideas about online collaboration and communication. But in order to make it more general and universal, more ideas were added until the entire thing could only be explained in a 90 minute mind blowing demo that left people speechless but a little later wondering what the hell this was for.

Let’s stop that from happening to the things we make. We don’t have to leave this job to The Researchers. We can all talk to the people who use (or might use) our software. We can go to a coffee shop and get feedback on wireframes for the price of a few cappuccinos. We can sit and watch some of our family members use the web, and make notes. We can try to spend a fixed percentage of every week talking to users. If we don’t, we’ll continue to widen what Jakob Nielsen calls the Usability Divide:

Far worse than the [digital] economic divide is the fact that technology remains so complicated that many people couldn’t use a computer even if they got one for free. Many others can use computers, but don’t achieve the modern world’s full benefits because most of the available services are too difficult for them to understand.

Whereas the [digital] economic divide is closing rapidly, I see little progress on the usability divide. Usability is improving for higher-end users. For this group, websites get easier every year, generating vast profits for site owners. That’s all great news for high-end users, but the less-skilled 40% of users have seen little in the way of usability improvement. We know how to help these users — we’re simply not doing it.

We know how to help these users — we’re simply not doing it. We don’t have a choice, we have to talk to them. It’s easy to start: take your laptop with you on one of your coffee breaks, and ask some people if you can show them what you’re working on. They’ll love giving you feedback, and you’ll walk away with a better understanding of the usability divide — and some very real ideas about how to narrow it.

More

  1. 1
  2. ...
  3. 165
  4. 166
  5. 167
  6. 168
  7. 169
  8. ...
  9. 204