Why it takes as long as it takes

Today at work I had one of those lengthy, impassioned discussions with the senior leadership of my company – the sort of discussion that makes me love working at a startup. We talked about our wishes for the product and our worries about where it is now, and we ended up with a list of urgent stuff that I suggested would take about ten months to accomplish.

“Really?” asked the CEO. “I thought some of this stuff would be easy.”

I reflected on this for a while after the meeting, trying to think of ways to describe why even the easy stuff takes much longer than she might think. A kind of flow chart started to develop in my head. At the beginning of the flow was the request for some “easy” new feature – something, say, that a business person could describe in three sentences. Then my imaginary flow chart split into basically two possible approaches for getting it done:

In one approach, someone (me, at my company) writes a detailed spec – enough so that an engineer knows exactly what the feature needs to do, and how to know if it succeeds in doing that. Writing such a spec is not done in a vacuum. Even with the “easy” features, there is some back and forth with the business, as well as the engineers. Then there’s often some work the visual designer has to do to make sure it looks right. All of this can easily take a couple of weeks – especially since working on this spec isn’t exactly my only job – and that’s without any concept testing or customer input. So, a couple weeks of spec-writing happen, then engineering begins. Let’s imagine an engineer has estimated that the feature will take him three days to build. He’s not necessarily factoring in the meetings and other distractions that will disrupt is engineering time, and he’s definitely not factoring in the five bugs he’ll have to urgently fix. All of this can conspire to push a three-day feature beyond the cutoff for the sprint it’s supposed to be a part of, and if it winds up overflowing into the next sprint, even by a day, that’s three more weeks that customers will have to wait. This is how an “easy” feature can take two months to find its way into the product – not from the time it was conceived, but from the time that work actually started. In my flow chart, I labelled this approach “getting it done right.”

I called the other approach “getting it done soon,” and the main difference is in the spec stage. In this approach, I don’t write a very detailed spec, there’s not much upfront back and forth with people, and I don’t get the visual designer involved. I write down just enough so that the engineer can start to work, and I make myself available to the engineer while he’s building the thing, so that we can flesh out the requirements together on the fly.

Once I laid these two approaches out in my head, I realized I’d basically described waterfall and agile.

I also realized that there’s a huge misconception among business people about agile development, which is that it’s faster than waterfall. “Getting it done soon” is not a good way to describe it at all. You might release something sooner than you would with waterfall, but then you inevitably have to keep building on it and enhancing it, release after release. Not to mention all the new bugs you now have to fix. Bottom line is, the whole thing is ‘done’ in about the same amount of time with either approach.

I should also mention that this version of agile is far from optimal. Even with agile, you should have well-written user stories that include good success criteria before engineering begins, and there should be a collaboration with the developers along the way, instead of just a handoff of requirements.

I thought about all this on my way home from work today, and after I got home I read an amazing couple of blog posts one of our engineers sent me:

The first is, Coding, Fast and Slow: Developers and the Psychology of Overconfidence by someone name Dan Milstein. There are so many nuggets of insight in this post, I won’t attempt to summarize it. It’s a total must-read if you want a wise perspective on why stuff takes as long as it takes, and much longer than anyone thinks it will. I like it better than this Quora answer to the same question, which is also fantastic.

The other post, No Deadlines For You! Software Dev Without Estimates, Specs or Other Lies, is Milstein’s (sort of) solution to the problem. I like to think I follow his strategy in the sense that I have a compulsion to make sure I fully understand the problem we’re trying to solve before I go too far down any solution path. But my way of pushing things back upstream to the ‘problem’ too often feels like pushback. For me, Milstein’s post provides a good template for asking the same kinds of questions while keeping things positive.

On Interviews and Evangelizing User Experience

I received a rejection email the other day from a man who had interviewed me for a job. I haven’t been rejected many times in my interview history, and I don’t think I’ve ever received a rejection email. So I find myself reflecting on it. I’m not sure if any further action on my part is expected, required, appropriate. Do I thank him for considering me?

It was a strange interview. A phone call. I don’t like interviewing over the phone. I feel handicapped without the social cues that come with face-to-face interaction. Also, I was sitting outside our midwife’s office (my wife was inside – we’re expecting our first baby), so the setting was not ideal for focus.

So I was unfocused, but not just because of the setting. I was complacent. I’m content with my work situation right now, so I don’t need a job. I approached the interview with the attitude that he needed to convince me, not the other way around. I suppose I was a little bit cocky. I expected him to be convinced already, and to offer me the job (eventually). The wrong attitude.

Also, he started the interview – a 30-minute phone call – by asking if I had any questions for him. This threw me a bit. Wasn’t I the one being interviewed? Shouldn’t he be asking me questions? When he finished answering my first question, he asked me, “what else?”

Eventually he asked me something – his only question during the entire call, as it turned out. It was a good one. To paraphrase: “Tell me about your experiences evangelizing user experience within an organization. How would you go about doing that?”

My answer was terrible. I rambled on about the importance of diplomacy and challenges around organizational politics (although I didn’t use those terms). I do think diplomacy and organizational politics factor in to the process of evangelizing user experience, but they’re hardly the most important considerations. It’s not the resonant or inspiring stuff.

I’ve worked hard to evangelize user experience in several organizations, through a variety of challenges and obstacles, so I’m disappointed in my answer. If I’d had more time to think about it, I would have started with the ‘why’ of it.

I believe I’m in the delight business. That’s the real goal of user experience design. Engineers can get on board with this idea as much as anyone. Who wouldn’t want to be in the delight business? I’ve helped engineers get excited about delighting customers. I’ve encouraged them to be a little competitive about it even.

Next I would have talked about science. User experience isn’t touchy-feely. It isn’t based on some designer’s intuition. You might start there, but there are lots of robust tools and processes for testing and validating. Quantifying success. Demonstrating objectively that A is better than B.

Finally, I might have talked about diplomacy, but I would have talked about how I would lead the conversation. It’s important to get engineers to talk about what’s working, what they’re good at, what’s going well. A lot of engineers are good designers, and it’s much more important to rally around what’s great than to identify the problems.

Ultimately, I don’t think it was the right job for me. The company is interesting, even important. But I don’t have enough of a connection to their industry or market. Still, I wish I’d put my best foot forward.

Not to make excuses, but a 30-minute phone call isn’t hospitable to best feet. When I interview people, I send them my most important questions in advance. I usually give candidates an assignment as well. Otherwise I’m only seeing their improv skills, their ability to think on their feet. This is an important skill for sure, but not the cardinal one.

Rdio, Spotify and the Paradox of Choice

Spotify has arrived in the US! Twitter was all abuzz when the announcement came, and lots of my friends jumped on board as soon as they could scrounge up invites. I was excited to sign up too, but then I procrastinated. And then procrastinated some more.

For one thing, I have a pretty big collection of music I’ve purchased over the years, and when you consider that, say, 500 years ago, many people on the planet had the opportunity to listen to music only a few times during their lives, maybe I should just be satisfied with what I already have. But it seems I’m not, because in addition to my own music collection, I use Pandora, and I subscribe to eMusic.

I like the “lean-back” experience of Pandora. I don’t have to make many decisions, and it often introduces me to great new music – which I then add to my wish list on eMusic.

That’s where the problem starts for me.

My eMusic wish list has become absurdly huge, and for $11.99 a month I can download about three albums (which is much better than iTunes or Amazon). The problem is, I’ve come to dread my “refresh” date, because I know I’ll be overwhelmed not only by what’s already in my wish list, but what’s available to me in the rest of the eMusic catalog. More than once I’ve left without downloading anything, telling myself I’ll come back when I feel more inspired or when I have more time to browse. More than once I’ve failed to come back, forfeiting my monthly fee (until recently, the policy was use it or lose it).

Based on my experience with eMusic, I hesitate to sign up for yet more music to choose from. But the problem is not just about choosing what to listen to; there’s also the problem of choosing which music service to sign up for.

There’s Spotify now, but there are also Spotify’s competitors – most notably Rdio and Grooveshark, but also Rhapsody, the old incumbent, Last.fm, and many more. I’ve read five or six blog posts comparing these services to each other, and honestly I still feel like I don’t know what the differences are, or what makes any one of them better than the others.

I think it boils down to this: People prefer Rdio’s UI (especially the mobile app). Spotify has a (slightly?) bigger selection (and better sharing features?). Grooveshark, as a crowdsourced service, suffers from inconsistent song naming and questionable licensing (the latter of which puts them at risk of being shut down). Also, they don’t have a mobile app. Last.fm and Rhapsody are fine services that just have the misfortune of being yesterday’s news.

This of course is a uniquely first-world problem, which lies in the psychological realm of what is lately being called “The Paradox of Choice.” Psychologist Barry Schwartz, author of the book bearing this title breaks it down into several sub-problems – two of which are relevant here:

  • Choice and Happiness – Basically an over-abundance of choice leads to depression. One study showed, for example, that people at chocolate-tasting events enjoyed themselves much more when they were given a smaller selection of chocolates to choose from.
  • Missed Opportunities - I know I’m not going to pay for eMusic, Spotify and Rdio, but I resist committing to any of them because I’m afraid of what I’ll forever miss from the others.

This all reminds me of the first time I saw one of those Internet-connected digital jukeboxes in a bar – the ones that will fetch almost any song you can think of. I was waiting my turn behind a guy who’d just put his money in it, and he was taking forever. Come on come on come on, I was saying in my head, until he finally finished making his picks. Then it was my turn, and I was completely flummoxed. Eventually I think I gave up.

There’s a bar in San Francisco called Lucky 13 that’s famous for its jukebox. It’s a wonderfully-curated selection of great punk music, plus a few all-time classics and a nod to pop. It’s easy to choose a great set in the Lucky 13 jukebox.

Carefully considered limits can be a good thing.

Here’s what I’m gonna do. I’m going to cancel my eMusic, because choosing three albums a month out of their massive catalog is the most acute problem in this mix. Then, I’m going to sign up for Rdio, not because I’m certain it’s better than Spotify, but because my friend Marisol works there.

Game Changers: Dyson

James Dyson was not happy with his vacuum cleaner. It wasn’t powerful enough, and he determined that the problem was the bag. The bag’s purpose was to catch the dirt, but as it filled up, it quickly compromised the suction. So he set out to create a bagless vacuum cleaner, and through much trial and error (5,271 prototypes according to some sources), James Dyson came up with something he called “dual cyclone” technology. His design used centrifugal force instead of a bag to separate dirt from the air, and the result was much more powerful than anything else on the market.

Today you’d be hard pressed to find a commercially available vacuum that requires a bag. Nearly all vacuums are bagless now. This fact alone is sufficient to call Dyson a game changer, but going bagless wasn’t enough for the iconic inventor. He did two other things to revolutionize this humble household appliance.

He let you see the dirt

This is the kind of counter-intuitive curveball that only a genius comes up with. Who wants to see dirt? Perhaps it was hubris on Dyson’s part. Showing off. Or perhaps he conceived it initially for sales demonstrations, as a sensible way to show how much more dirt the Dyson sucked up than the competition (he was not only the company’s engineer, but its pitchman). As it turned out though, everyone wanted to see the dirt. People delighted in knowing that this filth they could see with their own eyes was safely trapped in the cannister and no longer soiling their shag carpet.

He made it look like a toy

The Dyson vacuum is nearly all plastic, which isn’t so unusual now, but it was in 2002 when his DC07 first entered the US market. Higher end vacuums at the time were mostly sturdy and serious, and the all-plastic Dyson DC07 cost more than most of them. Instead of trying to hide his product’s “plastic-ness” however, James Dyson embraced it. He made his vacuum cleaners look like toys, using bright colors and whimsical shapes. As a result, you don’t feel like the janitor of your house when you vacuum with a Dyson.

It’s actually sort of fun.

Game Changers: Apple

This is intended to be the first of seven (possibly more) posts on game-changing business ideas.

It’s often difficult to recognize when something changes the game. A few months or years down the road, you can usually trace a trail of copycats and wannabes back to the original idea, but even then, sometimes it’s not immediately apparent how something changed the game, or which aspect of the thing was responsible.

Other game changers are instantly recognizable. The first game changer I planned to write about was the Apple iPhone, but after thinking about it for a few seconds, I decided to inaugurate this series of posts with an ode to Apple in general.

The Mouse and GUI (1983)

Apple has built its house on one game changer after another. They introduced the mouse and GUI concept to the mass market way back in 1983, which may be the biggest game change in the history of personal computing. In many ways, the mouse and GUI is the very essence of personal computing. If you’re not a developer or a sysadmin, can you even imagine a command-prompt universe?

“Lifesavers candy” iMacs (1998)

In 1998, Apple released its candy-colored “Bondi Blue” iMac, and the world said “hold on, you can design a computer?” Now every previously overlooked appliance and utensil is designed, from toothbrushes to toilet brushes.

The iPod and iTunes (2001)

In 2001, Apple unveiled the first iPod. Portable music wasn’t revolutionary (Sony’s walkman was first to blaze that trail). The ability to carry all your music with you was new, but not revolutionary either. The scroll wheel UI was innovative, and super efficient, but not game changing. The real game changing thing about the iPod was what it did for MP3. The iPod made MP3s mainstream, and it’s no coincidence that the music industry killed Napster just as the iPod took off, paving the way for the iTunes Store (or iTunes Music Store as it was called at the time).

The iPhone (2007)

In 2007, Apple launched the first iPhone. Hard to believe it was only four years ago, since it’s become so deeply nested in my life. Everyone was wowed by the touchscreen. So sensitive, responsive and precise. And the way it bounces! So kinetic! But it’s not the screen that makes the iPhone a game changer. I played with various touchscreen prototype devices back in 2002-2003 when I worked for Vodafone. I recognized the touchscreen as the future of mobile phones, and so did everyone else who used them. The touchscreen was simply inevitable.

So it’s not the screen that changed the game. It’s the App Store. Apple opened the mobile phone up to developers, and lo the developers didst come. Now there are lots and lots of touchscreen smartphones, and lots of would-be App Stores. There’s the Android Marketplace, Blackberry App World and the Nokia Ovi Store, not to mention app stores launched by the various carriers. But if you ask iPhone users why they don’t want to switch to Android (or ask users who did switch what they miss most), many will still say it’s the apps.


Singapore Airlines Web Apps

For a year starting in October 2004, I worked on a comprehensive redesign of the Singapore Airlines web properties, including all of the web-based applications (flight booking, check-in, frequent flyer program enrollment, mileage claims, mobile flight alerts, and many more).

My Role
User Experience Lead, responsible for product vision, research and strategy, the bulk of the hands-on design, usability test planning and execution. I also made substantial contributions to the content and localization strategy, business analysis work and creative direction.

Flight Booking Wireframes (excerpt)

The Flight Booking wireframes account for numerous scenarios, which is why a four-step flow required a 28-page document. The flow through the application differs according to the particulars of any given booking, in response to such factors as whether there are minors traveling, whether the destination country requires a visa, whether the traveler wants to choose seats or special meals, whether the traveler is a member of the frequent flier program, whether the traveler is redeeming miles to pay for the booking, whether Singapore Airlines is offering an upgrade promotion, whether the traveler needs to travel on certain dates or prefers to see prices within a range of dates, etc.

And many more variations can occur on the system side, based on flight availability for example, or flight availability for certain fare classes.

For simplicity, below are a few wireframes from the basic flight booking flow, minus many of the variations detailed in the original document.

In my designs I made extensive use of dynamic HTML (e.g. pop-out layers) and AJAX, to streamline the flow and minimize the number of page refreshes. This was not common practice on the web in 2004, and it was new for the Razorfish development team as well.

The core members of our team from Razorfish San Francisco worked on-site, in the client’s office in Singapore, coordinating with additional engineering support in the US.

I created more than 50 wireframes documents in all (more than 500 pages of final drafts only), to cover the many distinct applications and areas of the Singapore Airlines web ecosystem. In addition to the User Experience design, I planned and conducted usability tests in three languages and four cities, I co-authored the localization strategy, and I made numerous executive presentations to the Singapore Airlines corporate leadership.

Kyte Console

The Kyte Console is an enterprise asset management and analytics solution for digital video, audio and image-based content.

My Role (upfront and ongoing)
Competitive Analysis
Product Strategy and Road Map
Release Planning and Project Management
Business and Functional Requirements
User Experience Design
Usability Testing
Management of offshore development team based in Romania

Below is a small selection of requirements and wireframes extracted from numerous documents, starting with some conceptual sketches for the Kyte executive team and key customers, to ensure the product would cover certain benchmark use cases.

Kyte Mobile App Framework

The Kyte Mobile Framework is a template system based on the Kyte Mobile SDK. It enables Kyte customers to rapidly configure and deploy multimedia apps across the leading mobile platforms – iOS, Android, Blackberry and Nokia Symbian.


The iOS Human Interface Guidelines provide a robust design vernacular, so part of the project was to analyze the Apple guidelines and create general rules for how they would manifest in the Kyte Mobile Framework. As part of this effort, I mapped the various navigation paths.

And I specified the toolbar configurations and icons to be used with each type of media in the app.

The bread and butter of the Kyte Mobile Framework is mobile video – browsing, viewing and interacting (rate, comment, share).

In addition to mobile video, the Kyte Mobile App Framework supports audio content and image galleries (plus twitter and RSS feeds, event calendars and more).


The iPad app includes the same features as the iPhone, with a bigger UI canvas to play with.

The larger canvas provides opportunities for presenting content details and interactivity options within the media viewer, and supporting in-app background audio via a docked control bar.


The Kyte Mobile Framework for Android offers the same features as the iPhone and iPad app, but there are some important differences in the UI. Most significantly, the Android platform includes four standard hard keys for controlling the UI. Dedicated ‘Back’ and ‘Options’ keys mean these functions don’t have to be included on-screen.

Unlike the iPhone, Android does not offer a single out-of-the box media player, so we had to specify every aspect of the one we built from scratch.

Instapaper and Readability restore the pleasure of online reading

It would probably be better not to say anything. Advertisers won’t like it, and publishers who depend on ad revenue will like it even less. If this sort of thing catches on, there are only two possible endings, and they’re both bad.

I’m talking about two services that rescue online content from the twisted carnival of banner ads and assorted noise, and restore the pleasure of reading on the web. I’m talking about Instapaper and Readability.

With one click of a bookmarklet, Readability can turn this…

into this…

Instapaper does the same thing, but for stuff you want to read later. You just click a little “Read Later” bookmarklet, and the item is saved to a kind of to-do list. When you click the item in your list (or tap it, in the Instapaper iPhone or iPad app), it’s presented to you in its clean and simple glory, stripped of ads, navigation, related links, and anything else that might distract or annoy you:

But this is a bubble. A reading bubble. Most online publishers depend on the revenue they get from people eyeballing (and clicking, I assume, although who does that?) the banner ads. If services like Instapaper and Readability catch on, then there are two ways it can end.

The first possibility is a kind of arms race, where publishers find ways to prevent their content from being accessible in apps like Instapaper and Readability, then the apps find ways to work around the preventions, and so on. In this story, the best you can ultimately hope for is something like what has happened with RSS readers. Most big publishers only allow excerpts of their content to appear in the RSS feeds, and readers must visit the publisher’s website to read the whole thing.

The second possibility is some kind of advertising compromise built into Readability and Instapaper – maybe toned down ads that look more like sponsored text links?

So like any other bubble, enjoy this one while it lasts.

Kyte Mobile Producer

The Kyte Mobile Producer for iPhone and Blackberry is a companion to the Kyte Console – an enterprise media asset management and analytics solution. The Mobile Producer makes it easy for content creators to publish videos from iPhone or Blackberry to any number of end points managed through the Kyte platform. It’s an ideal solution for field reporters and other distributed production organizations.

Mobile Producer for iPhone

Mobile Producer for Blackberry

Kyte is the 360° video platform for live and on-demand content, recently acquired by KIT digital (NASDAQ:KITD). The Kyte Platform enables media companies and marketers to engage audiences across online, mobile, and social platforms through interactive video experiences.

© 2009 Shawn Smith | Creative Commons.
Entries RSS Comments RSS