Yesterday saw the Beta launch of a new Mint.com-type startup in South Africa called 22seven. They’re essentially aiming to give people better insight into the money they spend, and help them make better decisions about that. Or to put it in their own words:

We use smart information-gathering technology so our users can see all their financial stuff in one place. We’ve applied insights from behavioural economics so our users can better understand the way they think. And by employing principles of play, our users become more engaged, and more willingly engaged, with their money.

It didn’t take long for the banks to start freaking out about the security implications of giving your banking credentials to a third party, but there have also been some defenses of the safety of the service. Instead of rehashing those arguments, I’d like to make three quick comments about the new service.

An observation

I’ve been watching this unfold with fascination over the last 24 hours. Everyone who attended the launch event in Johannesburg seemed really impressed, but it didn’t take long for some (legitimate) concerns to arise as people started trying out the service:

My mom told me never to accept sweets from strangers and to give out my pin number… So… Yeah… Sorry 22seven…

— Cathryn Reece (@CathrynR) January 26, 2012

That’s a sentiment I agree with, but things started to go downhill a bit from there as the tweets became more and more negative. We’re a finicky bunch of complainers, aren’t we! But as I caught myself just in time before getting sucked into the negativity vortex, a phrase jumped into my head: Schlep Blindess. As in – these guys don’t have it. In Paul Graham’s excellent essay he describes schlep blindness as the inability to identify hard problems to solve:

The most dangerous thing about our dislike of schleps is that much of it is unconscious. Your unconscious won’t even let you see ideas that involve painful schleps. That’s schlep blindness.

He ends his essay by explaining how to avoid schlep blindness:

Some ideas so obviously entail alarming schleps that anyone can see them. How do you see ideas like that? The trick I recommend is to take yourself out of the picture. Instead of asking “what problem should I solve?” ask “what problem do I wish someone else would solve for me?”

And that’s why I admire the creators of 22seven. They’re working on a problem we all want solved, but most of us are too scared to work on. And for doing that, they deserve enormous credit.

A complaint

Speaking of finicky complainers, can I be one of those for a minute? Ok, cool. Obviously my first instinct was to scrutinize the design of the site, and even though there’s a lot to like about it, I have to mention a couple of things that I believe are not implemented correctly from a UX Design perspective.

First, forcing someone to wait for a Flash (!!) animation/introduction to load when they click “Register” is just not a good thing. Users don’t have patience for that stuff. If I ask for a registration form, my expectation is to see a registration form immediately. But my main beef is with the registration form itself:

Here are some of the issues:

• The text has very low contrast with the background which makes it difficult to read. Come on, everyone – join the contrast rebellion!
• We know that it’s bad to use multi-column layouts in forms.
• Speaking of contrast, what stands out are the phrases “About you”, “terms of service”, and “privacy policy”, while the primary call to action (“Yes, I do”) is a grey button on a dark grey background.
• While I’m nitpicking, if the button says “Yes, I do”, shouldn’t the title be “About me”?

We just don’t have to re-invent forms any more. The hard work has been done for us – we know how forms should be designed. And I don’t want to get into the Flash debate again, but why build this thing on a waning technology when you can build a responsive HTML web app that works on all devices?

A suggestion

Lastly, I’d like to offer a suggestion. If it is indeed true that 22seven has not met with South African banks yet, that’s a situation that should be rectified soon. In fact, my suggestion is that 22seven meets with one bank and work with them on an API solution that will allow them to access users’ banking information without having to store their credentials at a 3rd party. That’s what OAuth is for. And based on everything we know about Michael Jordaan (the CEO of FNB), wouldn’t FNB be the perfect bank to partner with on this? Once they’re on board, and FNB’s handsome and smart clients start using the service, the other banks are sure to follow.

I’d like to end where I began – on a positive note. I’m truly grateful that 22seven is tackling the banking/money management problem in South Africa in a very real and committed way. I think they vastly underestimated the backlash they would get from users when they’re suddenly asked for their online banking credentials (otherwise the web site would have been littered with trust-building explanations and images). But that’s a fixable problem, and so is my UX nitpicking – they’re not difficult issues to address.

So despite my complaining, I’m extremely excited about 22seven, and I’m rooting for them to succeed. I hope you’ll join me.

In 1955 David Ogilvy wrote a fascinating letter about his habits as a copywriter. One of his points jumped out at me:

I write out a definition of the problem and a statement of the purpose which I wish the campaign to achieve. Then I go no further until the statement and its principles have been accepted by the client.

This is applicable to design projects as well. If clients (internal or external) ask us for some quick wireframes, it is our responsibility as user experience designers to push back and make sure everyone agrees on the problem and the goals of the project first – before the design cycle starts. It sounds so obvious, but I see people falling into this trap all the time.

The product discovery process can take months, weeks, or even a few hours if there are tight deadlines. But it cannot take zero hours – that’s a recipe for disaster.

∞ Permalink

I love opening the App Store to see what updates are available for my iOS apps. Sometimes I forget to go there for a week or so and as the loading spinner comes up I play a little guessing game – will there be four updates? Seven? Double figures!?

Yes, I know I need to get out more. But I do believe my irrational excitement about something so inane points to an underutilized product marketing opportunity: Software version numbers as part of a delightful customer experience.

Before SaaS and the ease of over-the-air updates, version numbers made sense. In most cases v2.0 came after v1.0, and it was followed by v3.0, or maybe v2.1 for a non-significant update. Companies like Microsoft went a little more granular, but that was usually the exception. 1985-1992 saw the release of Windows 1.01 through 3.1, with only a few point releases in between^[1].

These days, with updates and releases coming with much more frequency than it used to, it’s not uncommon to see an update screen like this one:

Since there is no common standard for version numbers, it’s not easy to tell which of these updates are significant without going into the release notes for each one. I can guess that Google+ 1.0.4.2326 and Skype 3.5.84 are bug fix releases, but I can’t tell for sure. I have a feeling that WordPress 2.9 is a fairly big release, but is it in the same order of magnitude as Feeddler 1.11? No idea. Especially since sometimes a seemingly big point release turns out to be pretty unexciting:

Jeff Atwood is full of praise for the virtues of continuous software updates, and I agree with him. In The Infinite Version he explains how he stopped caring about version numbers after an experience with Google Chrome:

Chrome’s version number has been changing so rapidly lately that every time someone opens a Chrome bug on a Stack Exchange site, I have to check my version against theirs just to make sure we’re still talking about the same software. And once – I swear I am not making this up – the version incremented while I was checking the version.

From a software development perspective frequent software updates are great – you’re able to iterate rapidly and respond to bugs quickly. However, I think this continuing disregard for sensible version numbers is a mistake. We are missing out on an important part of the customer experience: that excited feeling that goes along with getting something new. For paid apps especially, giving users new features “for free” has the potential to delight them and build long-term loyalty. But how will they easily know that they’re getting something new without the visual cues of well-defined version numbers?

There is probably no easy fix for this. We can’t just send the Internet a memo that this is now how we’re doing things. But I hope that software developers will at least start seeing version numbers as part of their product marketing efforts. It would also be helpful to adopt a simple, rough guide to version numbers:

• x.0 for major redesigns or a re-imagining of the application (such as Path 2.0 and Instapaper 4.0)
• x.y for the addition of significant new features
• x.y.z for bug fixes and minor improvements

If we don’t go deeper than three levels (even if z is a four-digit number) and all developers adopt this basic taxonomy, users will eventually start recognizing the pattern. This will give them the necessary cues to understand and appreciate app updates. They’ll know to click through and read the release notes for x.0 and x.y release, but that it’s probably not necessary to bother with x.y.z releases.

This naturally leads into a discussion about the importance of writing good release notes to go along with a consistent version number strategy, but that’s beyond the scope of this article. I’ll just leave you with an example of an app that sees release notes as part of their… um… “brand experience”?

1. Of course, after 1995 all hell broke loose. Wikipedia lists monstrosities such as Windows 95 USB Supplement to OSR2, Windows XP Professional x64 Edition, and Windows Server 2008 R2 for Itanium-based Systems. ↩

Mike Rundle sums up how many of us feel about Twitter’s new new iPhone app in Twitter For iPhone Takes A Step Back:

The new app will be more inviting and accessible to new users, but I don’t like that this comes at the expense of the user experience and existing gesture shortcuts. There’s a way to make both novice and advanced users happy, and I hope Twitter 4.1 does a better job at appealing to all sides of their userbase than 4.0 has done.

If you step back from all the interaction and visual changes, this is the overarching theme that stands out for me as well. Expert users are suddenly left out in the cold. The new approach breaks the fundamental UI principle of flexibility and efficiency of use:

Accelerators – unseen by the novice user – may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

A great example of accelerators done right is Gmail’s keyboard shortcuts. They’re there to increase efficiency for expert users, but they don’t get in the way of novice users. The same functionality is there for all users, yet expert users have the ability to become more efficient by learning these shortcuts.

And that’s where the new Twitter for iPhone falls down. The biggest culprit is the now defunct swipe gesture on individual tweets. I’m with Ben Brooks on this one:

What is absolutely crazy – what drives me nuts – is the ditching of the swipe-to-act gesture. In previous versions you could swipe left or right on a tweet to slide open an action menu. From there you could quickly favorite, retweet, Instapaper, or reply to the tweet.

But let’s get real about this. I don’t think any of the design decisions the team made were an accident or an oversight. This is just all indicative of a company that is shifting the balance from being purely user-centered to a company that needs to sacrifice some user needs in order to make money. Dan Frommer summarized this well:

This is the beginning of Jack Dorsey’s real vision for Twitter combined with Dick Costolo’s vision for a real-time social advertising product. The main components: writing and Tweets, obviously; having conversations with other people; discovering what’s happening in the world through Twitter; and seeing a promoted message from brands here and there.

Spot on. I mentioned this morning that they should have just come clean and called the “Discover” tab the “Monetization” tab. Some have complained that users should be able to remove that tab, which is true, but it’s not going to happen because the balance has shifted. Our needs are going to be sacrificed more and more in favor of business goals^[1].

So here’s the truth in all of this: the new app isn’t a mistake. It’s a deliberate and effective redesign to reduce all the pesky “distractions” (like viewing your lists and favorites easily) so that you’re more likely to “discover” the “promoted messages from brands here and there”.

I don’t think we should pass judgment on Twitter for making these decisions to increase revenue – we want them to stay around, after all. But I think we can request and expect a 4.1 version that at least meets us in the middle. Simplifying is not just about taking features away, it’s about making complex actions easier to understand and use. We need our accelerators back, please.

1. I will say this though – I really like the “Connect” tab. The labeling might be horrible, but it’s a great feature.  ↩

When Google+ first came out there was plenty of praise for its UI design^[1], particularly the “un-Google like” design of the Circles feature. Oliver Reichenstein wrote:

Every interaction seems to have been thought through and designed until its last little bits (and those matter as much as the big bits). It even has room for some warmth (like the circle rolling away when you delete it) which is rare for Google’s cold UID approach.

We’re seeing the same thing with last week’s release of Path 2.0. I agree with the entire Internet on this: the design is gorgeous with lots of small delightful details. Here’s Geoff Teehan in Going down the right Path:

It feels familiar, but they’ve made some smart decisions that break away from the norm without wandering off into obtuse interactions or under/over-designed visuals. The decisions they’ve made not only make things better, they add personality and delight – something that is crucial, and often overlooked when designing something functional.

Here’s the thing. Google Circles aims to solve a real problem with social networks, but the solution is tedious. Path has a beautiful interface, but I can’t figure out what user need it’s trying to solve. And those issues are problematic if you want to get to product/market fit.

Google Circles

There are inherent problems with binary social networks. The idea that someone is either full-on in your life (and therefore has access to everything about you) or not at all is not how it works offline. You tend to share certain information only with certain groups of people. Only some people will be interested in photos of your new puppy, whereas those same people will probably not be interested in blog posts about your work.

Google Circles aims to solve these problems by allowing you to drag and drop people into distinct buckets, and letting you only share what you want with each circle. And yes, the UI makes it really easy to do this. It’s great design.

The problem is that it’s just too much work. I’ve long since given up trying to maintain my Circles, and I’m pretty sure I’m not alone. Circles also lost its core utility for me. After I put about 100 people into different buckets I couldn’t remember who I put where, and what I was supposed to share with which Circle. So I just gave up and started sharing everything publicly.

It doesn’t matter how great and fun an experience is, good UI design cannot fix a broken solution.

Path 2.0

I get the same feeling when I play around with Path. Let me be clear: I love this app. I wish I could dump Facebook and use Path all the time. Sometimes I go in and scroll up and down just to see the clock animation. When I open the app in the morning I tell it that I’m awake just so I can see what the weather is going to be like today. Fantastic design.

There’s a problem, though. I don’t know what I’m supposed to be doing with this app. Yes, I know it’s still early and not a lot of people are on the network yet (even though it’s now starting to gain some real traction). But here’s one reason the app might not have enough staying power to grow out of its initial “Hey, that’s cool!” phase: what unmet user need does it solve? Is it doing anything that’s not already being addressed by a number of general and niche social networks? I don’t think so.

Once again: it doesn’t matter how great and fun an experience is, good UI design cannot fix a broken solution. Good design can effectively differentiate a good solution, and bad design can completely ruin a good solution. But good design simply cannot make up for a solution that doesn’t address a core user need really well. As a recent post on ZURBlog proclaimed, people don’t buy products – they buy the benefit.

I’m afraid that in the case of both Google Circles and Path 2.0, they might just be flawed solutions wrapped in a layer of beautiful UI design. It’s fun to play with for a while, but when it inevitably becomes tedious you eventually just forget to use it. Forever.

1. When I talk about UI design in the context of this article, I mean specifically Interaction Design and Visual Design. I don’t mean to imply that Design = Making Things Pretty, or that UX is only about those elements. I use this term in the interest of simplicity since this is not an article about the elements of a User-Centered Design process. ↩

Update: Luke Bornheimer pointed me to his answer on Quora where he argues that Path’s biggest differentiator is how it easily enables private/public sharing.

I enjoyed On Culture and Interaction Design, an interview with anthropologist Genevieve Bell. In one section she discusses how we often design systems based on a cultural ideal, but in practice it ends up solving the wrong problem. She uses the example of security:

We design systems to keep systems safe and people write their passwords on bits of paper stuck to their systems. So, is it that people don’t care about security or is that the security we are designing is securing the wrong things? Or, are they just securing them in the wrong ways? Clearly we know that people care about the security of their homes, their possessions, their digital selves, but they adopt a range of patterns for doing it that are incredibly messy, complicated, and contradictory.

Passwords ensure that unauthorized people don’t get access to a system. But the mere fact that tools like 1Password exist to remove the need to remember passwords should tell us that we’re doing it wrong. Current password systems solve the problem from the wrong perspective: the system, not the user.

The problem runs even deeper. We’re not only solving the problem from the wrong perspective, we’re also introducing unnecessary complexity because of the way these systems are implemented. From a great post on the AgileBits blog:

Security systems (well, the good ones anyway) are designed by people who fully understand the reasons behind the rules. The problem is that they try to design things for people like themselves—people who thoroughly understand the reasons. Thus we are left with products that only work well for people who have a deep understanding of the system and its components.

This is why people have weak passwords and write them down on pieces of paper everywhere. It’s why the experience is complex and messy, and why we have to spend so much time building “Forgot password” flows when we could be spending that time making the core experience of our products better.

So what’s the alternative? I have a huge appreciation for the role that anthropology can play in the design of products and experiences – which is what Genevieve advocates in her interview as well. Ethnography (often called Contextual Inquiry in the user-centered design world) is the single best way to uncover unmet needs and make sure we are solving the right problems for our users.

In Ethnography in Industry, Victoria Bellotti defines ethnography as “a holistic, in-person, and qualitative approach to the study of human behavior and interaction in natural settings.” By using this method to understand the culture and real needs of personal security, we should be able to design a user-centered solution to protecting digital information. One that isn’t stuck in the downward spiral of designer myopia we often encounter in proposed solutions to complex problems.

Security is an impossible industry to reinvent, you say? Maybe. But the problem does remind me of something Matt Legend Gemmell says about innovation in his excellent post Copycats:

The lesson of the technology industry in the past five years is that really successful products dare to NOT copy. They’re pure, in that they’re actually designed from first principles – they’re based on the problem and the constraints, without being viewed through the lens of someone’s existing attempt. You know, the kind of thing you actually wanted to work on when you got your degree and were still unsullied by the lazy, corporate machine.

So who wants to take a crack at it?

In The Pummeling Pages, Brent Simmons sums up the experience of reading on the web, which is something I’ve become increasingly frustrated with as well:

I was there because I just wanted to read something. Words. Black text on a white background, more-or-less. And what I saw — at a professional publication, a site with the purpose of giving people something good to read — was just about the farthest thing from readable.

The site has good writing. But the pages do everything possible to convince people not to try. “Don’t bother,” the pages say. “It’s hopeless. Oh — and good luck not having a seizure!”

I see the sentiment echoed everywhere, including tweets like this one by Alpesh Shah:

Just to be clear about what we’re talking about, here are a few examples that illustrate why there is such a growing frustration with reading on the web.

First, here is an article on Harvard Business Review that not only blocks me from reading anything until I click to dismiss the ad, it also messes with the other ads on the page:

Here’s a story from Cracked.com, where in my unscientific estimation about 15% of the page above the fold is devoted to the actual text of the article:

And finally, an example from Search Engine Land that illustrates the following sentiment in Brent’s article:

They’re filled with ads and social-media sharing buttons — and more ads. And Google plus-onesies and Facebook likeys. And also more ads. Plus tweet-this-es. Plus ads. (And, under-the-hood, a whole cruise-ship-full of analytics. The page required well-more than 100 http calls.)

Is this the future of reading on the web? I sincerely hope not. I keep reminding myself of these words by Jeffery Zeldman:

Most of all, I worry about web users. Because, after ten-plus years of commercial web development, they still have a tough time finding what they’re looking for, and they still wonder why it’s so damned unpleasant to read text on the web — which is what most of them do when they’re online.

The scary thing is that Zeldman wrote that in 1999 (he revised the post slightly in 2005). And many years later the experience of reading text on the web seems to be getting worse, not better. As I wrote in The demise of quality content on the web, I’m worried that the wells of attention are being drilled to depletion by linkbait headlines, ad-infested pages, “jumps” and random pagination, and content that is engineered to be “consumed” in 1 minute or less of quick scanning – just enough time to capture those almighty eyeballs.

As advertising clickthrough rates continue to drop, the ads become more desperate and invasive, and readers are starting to notice and do something about it. I’m doing the majority of my reading in RSS and Instapaper where I can read in peace without being pummeled by distractions.

The thing is, there are better ways to make money from writing – ways that are more respectful of readers. Ad networks like The Deck come to mind, as well as the growing number of sites that offer memberships (like The Loop and Daring Fireball).

It’s time for publishers to think different.

I completely agree with Gabe Weatherhead’s views on apps made for kids in The Value Of App Reviews:

My number one reason to give a bad rating and review is when an app made for kids has both up-sell and review requests plastered all over the screen. They are trying to prey on small children tapping anything that pops on the screen. If you make a kids app, do not put links to your other apps in the game. Put them in the preferences. Put them in the app description. Hell, put them in some kind of app documentation. But when they are in the game, you are telling me that you’re shady and unscrupulous and I can’t trust your app.

This is a dark pattern, and I simply delete the app if I come across this kind of design. For some better patterns to follow when designing apps for kids, see Luke Wroblewski’s Touch-based App Design for Toddlers.

∞ Permalink

It seems like everyone was looking for developers at this year’s Tech4Africa conference. We heard some fantastic startup ideas, and each pitch was usually punctuated with something like, “And if you know any good developers, please let me know.” Cennydd Bowles made the following observation after the first day of the conference:

I understand and support the rush to find good developers because I love all the local ideas entering the market (much of my own talk at Tech4Africa was dedicated to improving developer environments). But I’m concerned about tech startups^[1] going on the hunt for developers without also looking for quality User Experience Design skills at the same time^[2]. In Tart Up Your Startup! Erika Hall explains the dangers of ignoring UX in startups:

You are making UX design decisions as soon as you specify anything you expect another human to interact with, as soon as you specify anything that has implications for how a human might interact with it. Of course, you are are also making system design decisions, but we assume you are comfortable with that sort of thing.

So don’t pretend like you aren’t making design decisions already. And don’t make them by omission. You cannot NOT design something. The floor of Silicon Valley is littered with the crumbling husks of great ideas—useful products and services that died in the shell before they hatched out of their impenetrable engineering-specified interfaces.

So if this is so important, why are most South African tech startups (and large companies, for that matter) not looking for UX designers? In this article I’d like to explore what I believe the three main, interconnected explanations are, and how this is actually an opportunity for the design community to prove the value we can add to product development. I’d love to hear your thoughts and observations on this topic as well. If you think I’m missing the boat, please let me know.

1. Hiring is expensive

A very legitimate concern most startups have is that hiring people costs a lot of money, and making the wrong decisions on who to get involved can be extremely costly. So naturally the first requirement is a developer who can actually build the product. It’s logical, and the prudent thing to do. The danger is that you could end up wasting a lot of money by going down the wrong path if you don’t have design skills on board from the beginning.

It also has to be said that in some cases, startups take the considered approach to, as Erika Hall puts it in her article, “Get your nerds to swot up on usability principles and muddle through, yo.” It’s definitely an option, but if it doesn’t work it can turn out to be an expensive detour.

2. Limited visibility into the value of User Experience Design

As we were discussing this topic over breakfast at the conference, @ndorfin brought up the point that for most people, Design still means Graphic Design, or more specifically, Graphic Design for print. So it’s no surprise that tech startups don’t think about the need for a designer – they don’t see the value that something like billboard design could bring to their interactive product.

UX is, of course, a much larger concept used to describe the process of understanding a market and finding solutions that work for that market. User Experience Designers solve problems by uncovering user needs and helping to create products that meet those needs. Until an understanding and appreciation of the benefits of UX become pervasive in the South African tech space, it will not be highly sought after.

I want to be very clear about this. It’s not the tech community’s fault that the benefits of UX are generally not well understood. It’s our fault. As designers it is our responsibility to show others the value of what we do in a convincing way (i.e., irrefutable evidence of revenue/conversion increases). We can’t expect people to come ask us what we do like we’re at a high school dance waiting for someone to notice us. We have to make ourselves known, and do it loudly.

3. The current maturity level of User Experience Design in South Africa

UX is still in its infancy in South Africa. In @cennydd and @boxman’s session at Tech4Africa called March of the UX Designers they shared their views on the maturity cycle of a particular skill set in an organization. They talked about six distinct stages:

• Unrecognized
• Interested
• Invested
• Committed
• Engaged
• Embedded

Most organizations in the US and UK have reached at least the stage where everyone is committed to making UX a priority. Some are engaging people from multiple disciplines in the process, and others go so far as to have deeply embedded cultures of Design. In most South African organizations it feels like User Experience Design is still mostly unrecognized, or at best something there’s mild interest in (with a few notable exceptions).

Again, I want to be clear that I’m not passing judgement here. I’m simply pointing out that we are at the beginning of a natural cycle that the UK and US have gone through as well. It’s a cycle we should be aware of, but it shouldn’t paralyze us. It’s actually an exciting place to be – we have an opportunity to make a real difference to how organizations do business.

What we can do about it

There’s one thing I know is not an option for us as a UX community in South Africa. We can’t play the victim and go sit in a corner, drawing sketches on napkins while we complain about how no one understands us. We know that when users struggle with an interface it’s our fault, not theirs. How is this situation any different? If we’re a misunderstood or unrecognized industry, how is that not our fault, and our problem to solve?

The only way to get UX to the next level of maturity in South Africa is to do what the US and UK did: we need to become childishly loud about what we do and how we can contribute to better products that make more money. Whether you do research, write content, or spend most of your time in OmniGraffle or Photoshop, it’s time to explain to our companies, our clients, the Internet, and the public space in South Africa what UX is and what value a user-centered design process can bring. We need to make it impossible to ignore UX during product development.

If we do that effectively, maybe next year we’ll see demand for an additional skill set at Tech4Africa…

1. I’m refering specifically to startups that sell physical/virtual products/services, not the agency model of selling time. ↩
2. I’m making an and argument here, not an either/or argument – both types of skills are needed. ↩

Peter Merholz describes Instapaper creator Marco Arment‘s approach to design in Craft in Interaction and Service Design:

Instapaper shows the power of approaching experience design as a craft, as opposed to some kind of massive organizational process. Too often companies launch something and then move on to whatever’s next. Instapaper shows what happens when you go deeper and deeper and deeper into something. Unlike Microsoft or Adobe, who simply tack on features with every new release, Marco, instead, refines the design, honing it, polishing it, like his app is some jewel. I’d love to see companies approach service design the way Marco has. It would require a fundamental shift in how they work, but the results could be quite beautiful.

How often do you hear the words “We’ll get to that in Phase 2″? And how often do you actually get to do “Phase 2″? It’s a running joke in the software industry that calling something a “Phase 2 feature” is another way of saying it will never happen. There are just too many squirrel projects, too many Shiny Things that need to get done.

It doesn’t have to work like that, though. Small, dedicated teams who have autonomy and a clear decision maker can focus on one area of an experience for an extended period of time. This can work even in large organizations, but it requires trust and a long-term vision, both of which can be hard to find in big companies. It is the only way to bring craft and care to a design cycle that’s often treated too much like a conveyor belt.

∞ Permalink