The social media manager at my friend Paul Cartmel’s company needs to track 3 different Twitter accounts on Klout, so he sent an email to their support team to find out how to log out of their iPhone app. This was the response, which Paul kindly forwarded to me:

Yep. You have to delete the app to log out of it. This example reminds me of what Adaptive Path calls the cake model of product strategy. Watch this short video about it before you continue reading:

What Klout did with their iPhone app is a classic “Dry Cake” approach. Even though they probably have additional functionality planned to make the app tasty with filling and icing, the current iteration is dry and not very exciting since key functionality is missing. You can’t do anything except see the Klout scores of yourself and a few other people connected to you — there is no way to search for other users.

What they should have done is build a cupcake first — an iteration that feels complete, even if it doesn’t have an entire roadmap’s functionality built out yet. It should support basic actions like logging out and searching for other users. And despite not having all the features of the web site, it should be an app that can stand on its own, one that is engaging and desirable with the functionality it does have. It’s so much fun to go from cupcake to cake to wedding cake if that first iteration is something that users are excited about.

So when you think about building your own product, remember to make your minimum viable product a tasty cupcake, not a dry cake with some vague promise of filling and icing somewhere down the line.

Christopher Butler wrote a good post on the relationship between Ego and Design, and how to structure design feedback better. It’s called Your Ego Is a Bad Designer, and he starts by explaining why development projects usually begin to go wrong during the design phase:

Design—specifically, when we start making visual decisions—is the first point in a project when we begin to engage one another in emotionally vulnerable ways. Every point in the process is an opportunity to second guess who is in control? and how do I feel about that? but design lacks the social decorum of sales negotiations and the regimentation of information architecture planning that would otherwise provide some structure for handling these potential conflicts. There’s simply no way to anticipate how the client will feel upon seeing that first mockup, or how you will respond, designer, to that initial deluge of feedback.

He then shares his approach to sharing work with clients, and structuring their feedback in a positive and helpful way. I also like the way he makes us as designers responsible for the success of a project:

We don’t fail at design because we lack tools, time, money, or the right clients. We fail at design because we lack insight. We don’t fail at design, we fail our design.

For more on design critiques, see these three great posts:

• Do you want critique, or a hug? How to gain valuable criticism on your design
• Moving from Critical Review to Critique
• Giving Better Design Feedback

Nishant Kothary takes a passage from a Jay-Z book and turns it into a great commentary on grid-based design in Rap it in a Grid:

The reality is, a grid makes the act of solving design problems seem predictable, but says nothing for supplying the appropriate design solution. The grid is akin to the beat. But it’s hardly ever the flow, which is the true design solution.

I’ve never fully bought into the “user experience cannot be designed” argument. You could say I’m biased because user experience design is how I choose to make my living, but I would (surprise!) disagree with that as well. Consider this paragraph from Chris Dixon’s excellent post The experience economy:

Experiences make people happier than products (a fact that scientific studies support). The popularity of experiences like music concerts has skyrocketed compared to corresponding products like music recordings. Apple, the most valuable company in the world, maniacally focuses on product experiences, down to minute details like the experience of unboxing an iPhone. Customers want to know where their food and clothes come from, so they can understand the experiences surrounding them. The emphasis on experiences also helps explain other large trends like the migration to cities. Cities have always offered the trade-off of fewer goods and less space in exchange for better experiences.

The main argument against experience design is that we can’t control context of use, no matter how hard we try. But the above examples are all cases where we can control enough of the context of use to make a reasonable assumption about the type of experience the majority of users will have. The same goes for web sites — through creativity and a little user testing, we can get to a similar level of comfort with how most users will experience our sites/apps.

So, don’t give up, experience designers. We can build great experiences for our users (while also meeting business goals at the same time).

Matt Simmons wrote a great post on designing elegant solutions for when users inevitably make mistakes on your system. In Engineering Infrastructures For Humans he uses the example of ash trays in airplanes to make his main point:

You don’t engineer your systems with the belief that none of your computers will ever break. That’s insane; you KNOW they’re going to break. So don’t assume that your users will never break the rules. Build in graceful failure as often as possible, whether you’re designing a user interface or a security policy.

The ash tray story is really interesting, so be sure to click through to his post.

South African bank Absa just rolled out their new online banking portal. There are two things about this launch that raise red flags for me. First, from ABSA rolls out new Internet Banking revision:

This launch follows a successful trial with the bank’s 36 000 employees over the past few months. The trial allowed the project team to identify and solve any defects and gauge the response from users, via over 1 300 feedback emails received from employees.

It’s shocking that we still have to talk about this, but let’s just state it again, as clearly as possible: You are not the user. You cannot test a system on employees — who know all the intricacies inside and out — and think that you’ve done appropriate user testing. There are plenty of solid arguments and evidence for this, but for now I’ll just quote Jakob Nielsen:

One of usability’s most hard-earned lessons is that “you are not the user.” If you work on a development project, you’re atypical by definition. Design to optimize the user experience for outsiders, not insiders. The antidote to bubble vapor is user testing: find out what representative users need. It’s tempting to work on what’s hot, but to make money, focus on the basics that customers value.

Also see Myth #14: You are like your users and You are not your user, which both have a lot of great points and research around this.

Second, there’s this quote from the Head of Retail Markets at ABSA:

The development of Absa Online saw up to 140 individuals, working across three continents, putting in an astonishing 450 000 man-hours of development work. Four million lines of code were written in this, a “first-of-its-kind” technology deployment in South Africa.

Well, that is just silliness. As one of the commenters on the article points out, it’s Bill Gates of all people who said, “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.”

The size of the project, how long it took, and how many people worked on it is completely immaterial. What matters is if the thing works well to help real users accomplish their goals. I really hope it does, because this looks like an outrageously expensive project. Hopefully it doesn’t become South Africa’s version of the Four Seasons $18m redesign.

In Designing Ideas Paul Scrivens reminds us that distraction-free writing apps aren’t new - typewriters and pen & paper have been around for a very long time. He then encourages us to look beyond our immediate time and medium for ideas on how to solve design problems:

The problem with designing new ideas is that we are too busy looking at what the people are designing around us to realize that many of the solutions to the problems we are facing have been solved already in a different time.

You will never be first with a new idea. You will be first with a new way to present the idea or a new way to combine that idea with another. Ideas are nothing more than mashups of the past. Once you can embrace that, your imagination opens up a bit more and you start to look elsewhere for inspiration.

This is partly why I’ve spent so much time reading up on architecture. It’s a mature, related craft that can teach us a great deal about web design - arguably more than Dribbble can.

I just finished reading Frank Chimero’s The Shape of Design. My closing remark on Readmill:

Highly recommended to anyone who wants to step back and get a sense of the state of design beyond the tools that we use. It makes us think about the reasons why we design, and how to give our work purpose and meaning. I found part 1 to be the strongest, but it’s a quick, easy read throughout.

You can follow the link to see the highlights I made - there are some really great quotes in there, such as this one:

Design doesn’t need to be delightful for it to work, but that’s like saying food doesn’t need to be tasty to keep us alive. The pedigree of great design isn’t solely based on aesthetics or utility, but also the sensation it creates when it is seen or used. It’s a bit like food: plating a dish adds beauty to the experience, but the testament to the quality of the cooking is in its taste. It’s the same for design, in that the source of a delightful experience comes from the design’s use.

In related news, I thoroughly enjoyed reading this on the Readmill app for iPad. I will try to read books with this app whenever possible from now on, with the Kindle as a backup if I can’t find the book as DRM-free ePub. The reader itself needs a bit of work to get to the standard that iBooks set, but the social features are really great. I love seeing who else is reading the book I’m reading, what they’ve highlighted, etc. Readmill embraces the digital reading experience in the best way that I’ve seen so far.

Hey, I dislike the word “gamification” as much as the next guy. The topic of game mechanics has been twisted and applied to everything with almost as much success as the recent “infographic” craze. And yet, I can’t help but link to this excellent post by Michael Lopp. In Two Universes he provides one of the few worthwhile explorations of game mechanics in software that I’ve seen:

The plethora of online Photoshop tutorials demonstrate its power and its flexibility, but I believe they also demonstrate its poor design. Think about it like this: what if each time you plunked down in front of World of Warcraft, you had to spend an hour trying to remember, wait, how do I play this?

Great design makes learning frictionless. The brilliance of the iPhone and iPad is how little time you spend learning. Designers’ livelihood is based on how quickly and cleverly they can introduce to and teach a user how a particular tool works in a particular universe.

His observations on what it takes to motivate people to learn are spot on.

Jeff Atwood starts his article This Is All Your App Is: a Collection of Tiny Details as a post about cat feeders, but stick with it. It’s gold:

Getting the details right is the difference between something that delights, and something customers tolerate.

Your software, your product, is nothing more than a collection of tiny details. If you don’t obsess over all those details, if you think it’s OK to concentrate on the “important” parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis ”“ you’re not creating great software. Someone else is. I hope for your sake they aren’t your competitor.