Jake Knapp writes that you can build better products by designing the marketing first:

Okay, let’s pretend I grab you and stuff you in a DeLorean. We time travel a few weeks into the future. Your latest project has just been released.

Imagine you can see the launch page. It has a nice simple headline explaining the appeal of your product, with a couple of secondary call-outs. You print the screen, hop back in the DeLorean, and return to the present.

With this glimpse of the future in hand, your team will be better at focusing on the core of the product. If it’s on the launch page, double down! If it isn’t, think hard before spending any time on it.

That reminds me of a similar technique used by Amazon called “working backwards”. It’s outlined in this Quora thread:

For new initiatives a product manager typically starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product’s customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.

Once the project moves into development, the press release can be used as a touchstone; a guiding light. The product team can ask themselves, “Are we building what is in the press release?” If they find they’re spending time building things that aren’t in the press release (overbuilding), they need to ask themselves why.

These are both great techniques to prevent scope creep and ensure that you’re building products that have clear user benefits.

As part of the inaugural “Great IxDA Debate” at Interaction 12, Jeff Gothelf was asked to defend the position “Interaction design is not a respected design discipline”. He made the following point in his opening remarks:

Most of our employers still see us as wireframe monkeys and pixel pushers. They see us as annotators and documenters ”“ not as problem-solvers and product designers. They evaluate us based on our portfolios of decontextualized wireframes asking not how we solved the problem or what the outcome was but instead wondering what tool we used to create the straight lines in our wireframe decks.

I agree with Jeff that there are some major barriers to getting User Experience fully embedded specifically in large organizations. I think the core problem is that most large companies still don’t see Product (the site or app) as a “profitability lever” that can be pulled. Instead, they focus on two things that have stood the test of time through years and years of MBA classes: Marketing and Pricing. These levers usually result in immediate returns, and they are easy to quantify and measure over time.

For Marketing (including SEO and PPC) the equation usually looks this: More money invested = More traffic = Increased revenue.

For Pricing, it looks like this: Lower prices = Increased sales = Increased revenue (albeit at lower margins).

But Product lacks the immediacy and simple quantifiability that make the other levers so enticing. One version of the Product equation could look like this: Investment in UX = Increased conversion and/or better experiences = Long-term effect on loyalty, trust, and profitability. That doesn’t quite roll off the tongue the same way “MO’ MONEY, MO’ TRAFFIC!” does.

The consequence of UX not being seen as an essential profitability lever is that it’s rarely adequately represented in the upper echelons of large organizations. It’s mostly seen as an auxiliary function down in the trenches as opposed to a core foundation of the business.

I also agree with Jeff that we are partly to blame for this situation:

The fact that those within the profession struggle to unify around a name for our profession hurts our credibility.

Yup. I’ve never seen an industry so intent on undefining itself (like here, here, and here). But I digress…

The fact that our leaders cannot identify in concise and consistent terminologies what it is that we do, hinders our progress into the mainstream of the corporate world. The fact that we, as practitioners, fail to consistently and convincingly describe what we do and the impact we have on our teams, products and companies, speaks volumes towards the progress we still have to make to get the respect we deserve and that is afforded to all these other professions.

So how do we begin to solve this problem? We do it by ensuring the work we do is credible, consumable, and relevant:

• Credible: Use solid methodologies, accurate measurement, and success metrics that are clearly defined and agreed upon upfront.
• Consumable: Tell the story really well to business stakeholders, using plain language to explain our process and its benefits, as well as the business results.
• Relevant: Forget about squirrel projects for a while, and focus on things that are important to the business, like Checkout or Landing page optimization.

We should apply UX principles to our internal clients too. We know that organizational leaders are measured by (and therefore focused on) business results. So we need to not only design our Products to accomplish that, but we also need to design our deliverables in a way that shows the value of UX in clear and irrefutable ways. That’s how we get more CPO’s and CXO’s in large organizations.

And for the love of all that is holy, can we please just pick a name for ourselves and stick with it? I know there’s plenty wrong with the term User Experience Designer, but it’s the most recognizable thing we’ve got. It’s akin to attempts to replace the save icon - yes, it might not be appropriate any more, but why break users’ mental models about something that is so instantly recognizable?

Fabio Sergio wrote a slightly rambling but very interesting post called The Myth of the Brand New Innovation Myth. He takes on some recent opposing views on innovation and creative thinking. Should you listen to customers or not? Should you work in an environment where you can do your thinking alone, or collaborate? Sergio’s point is that (surprise!) it’s not that simple:

I don’t think there is an archetypal, simplistic image of what type of personality or process best fosters innovative thinking, or even what type of physical working environment can best support a creative culture. That view of the world is too polarized. In my experience there is no single specific behavioral trait, methodological approach, or carefully-selected set of contextual factors that guarantees success in the ability to think differently and translate that thinking into success in the market.

He goes on to say that the truth doesn’t lie in any of these extremes, but somewhere in between:

That said, there is indeed a common trait in the typical way creative thinkers approach challenges: they can comfortably hold opposing thoughts in their heads and get to work. [”¦] Informed intuition. Controlled chaos. Abductive analysis. This is often the mindset of successful creative, innovative thinkers: seeing opposites and apparently contradicting goals not just as a potential for dissonance, but as an opportunity for dynamic harmony.

It’s a much more balanced and realistic view than some of the other black-and-white proclamations of truth we’ve been seeing lately.

James Hague in Don’t Fall in Love With Your Technology:

Don’t fall in love with your technology the way some Forth and Linux advocates have. If it gives you an edge, if it lets you get things done faster, then by all means use it. Use it to build what you’ve always wanted to build, then fall in love with that.

I know I’m in danger of that with iOS, Mac OS X, and my new-found love affair with text files and Markdown. Hoping that knowing I have a problem is indeed half the battle.

I can only imagine the miles and miles of chaotic complexity that designers and developers had to wade through to arrive at the simplicity of Clear - a new To Do list app for the iPhone. As I started playing with the app, Rebekah Cox’s definition of design kept popping into my head:

Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.

And the decisions that Clear made are as close to perfect as I’ve ever seen. I can picture the endless, difficult meetings and arguments that must have happened to decide what features to include in the app. Should we have Projects and Contexts? No. How about Due Dates and Filters? Nope. Well, why not!? Because Clear is a prioritized list of tasks that is fast and easy to edit. That’s it. Nothing less, nothing more.

It reminds me of the Quora thread on why Dropbox became so popular:

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

But let me stop gushing for a minute and step back a bit. Clear (which is getting quite a bit of attention) is absolutely fantastic as a way to view and prioritize a simple list of tasks, but it’s not a replacement for hardcore task management systems. Omnifocus will remain the application I use for all my work projects, and it’s always open on my Mac and iPad during the work day. But Omnifocus is hopeless overkill for simple tasks like “Make a car appointment” or “Get coffee at the store”. And that is the gap that Clear fills so effectively.

Clear is focused on two things that make it vastly superior to other similar apps:

• Speed. It’s really fast. When it starts up you can instantly start typing. This is crucial to quickly capture that all-important thing you don’t want to forget. I still die a little bit inside every time I see the “Optimizing database” message while I wait for Omnifocus to start up.
• Effortless editing. It’s completely gesture-based - no chrome, no fluff, no fancy visual design. You tap, you type, you swipe, you close. These gestures are easy to learn and intuitive:

Francisco Inchauste calls Clear “an app for the future”, and I completely agree. It feels different, but it feels right. And despite its (appropriate) lack of visual extravagance, it has an attention to detail that reminds of the meticulous design of Path. For example, when you create a new list and there are no to do items in it yet, you get a random quote about getting things done:

I’m trying hard to find something negative to say about Clear, because every app has room for improvement. But at the moment my judgment is slightly clouded by how impressed I am with this team. It’s so hard to resist the temptation to build an app that tries to solve every problem for every person in the world. These guys walked through that fire and emerged on the other side probably bruised and battered, but also with a flawless app for listing tasks and editing them quickly. Want more in your To Do list app? Shut up and go buy Omnifocus.

Alan Mitchell on the problems with Big Data and the value of what he calls Very Small Data:

So there are two classes of data which help solve different types of problem. Big Data is statistical and deals with general trends and patterns; Very Small Data is specific and deals with getting things done: gathering the information needed to make a decision, to make an arrangement, or to get some administrative chore done. Because it’s Very Small and rather mundane and specific, it doesn’t seem as glamorous and important as Big Data. But it is.

He goes on to discuss four major problems with Big Data, and the enormous opportunities that exist in the area of Very Small Data. It’s an essay well worth your time.

Rachel Swaby wrote a great piece for Wired on the complex problems that Dropbox had to solve to arrive at the simple solution they have today. This sentence stopped me in my tracks:

Almost immediately, those who didn’t actively search out the solution outnumbered early adopters.

Think about that. About 100,000 early adopters signed up for the Dropbox service in the six months leading up to the official launch. But because these early adopters started sharing folders with coworkers, friends, and family, they immediately hooked an entire network of regular users into the service.

Dropbox solved a problem most people don’t know they have, and made the solution simple enough so that non-tech savvy users immediately get the beauty of it and how it can fit into their lives. That’s innovation.

Jakob Nielsen explains why saying “but it’s cheap!” is not a good excuse for the Kindle Fire’s bad user interface design:

The difference between user interface design and hardware specs is that better usability is derived from one-time expenses for user studies, design iterations, and coding - whereas beefier hardware (say, adding a camera) is a repeated expense for each additional unit manufactured.

This means that even cheap devices can have great usability because the cost of better research and design is amortized across millions of devices. This is why usability has stupendously high ROI for any big project.

I also like John Gruber’s take on the hardware/software distinction:

[T]hat’s the advantage of software over hardware. You can omit an essential feature and then hustle to get it into your first major update. Good luck adding volume buttons to your Kindle Fire.

Does this mean it’s ok for the first version of the Kindle Fire to have a low-quality UX? Here’s Nielsen again:

I understand why Amazon might want to ship a poor product in late November rather than a good product in February: they want to catch the holiday shopping season. Whether the extra sales are worth the brand damage from a low-quality user experience is difficult to judge.

Amazon has a history of doing this kind of thing. The first Kindle eReader was not a great product, and it didn’t get good reviews. But they kept at it and turned it into something truly great.

This points to one of the main differences between Apple and Amazon. Apple waits until an experience is as close to perfect as possible before they ship. Amazon gets something out there as soon as possible, but then - and this is important - they don’t just move on. They keep working at the product until it reaches an experience they’re happy with.

Both companies are very successful despite their different philosophies on when to ship a product. It proves that we should get over this idea that everyone should just copy everything Apple does. There’s more than one successful business strategy.

I’m sure the Kindle Fire will follow the same trajectory as the original Kindle eReader and become a great device. Eventually. Still, let’s not kid ourselves - the current one isn’t great.

Sometimes, you don’t need glitz; you need plumbing.

That’s Charles Arthur in Goodbye Delicious, hello Pinboard, explaining why The Guardian is dumping Delicious as their social bookmarking service. Let me ask you a question. Which of the following two screen shots is prettier?

Delicious:

Pinboard:

Delicious, right? Now let me ask you another question. Which site is more useful as a social bookmarking site? It’s ok, I’ll answer for you: it’s Pinboard.

Pinboard’s aesthetic[1] is fairly bland, but the  sparse, table-like layout is the best way to organize the vast amount of information you collect on the Internet. The aesthetic fits the purpose of the app. But wait, there’s more. It lets you import from Twitter, Instapaper, and Google Reader (well, back in the day when Google Reader still supported public sharing). It has browser bookmarklets that work effortlessly. It integrates smoothly with a variety of RSS Readers. Sorry for the cliché, but it just works.

Meanwhile, Delicious has become slow, it has constant availability issues, and the aesthetic keeps getting more extravagant. This actually reduces its utility by obscuring the app’s core features. Social bookmarking is about two things - tagging the things you’re saving, and searching for those thing later on. That’s it. The new Delicious owners are apparently trying to turn it into something more, but whatever that something more is, I’m not buying.

Anyway, back to glitz and plumbing. As I’ve mentioned before, great aesthetic design builds trust, increases engagement, and elicits the appropriate emotional responses to a brand. But glitz is something else. Glitz is about making things shiny without asking what the thing should look like to fulfill its primary purpose.

Social bookmarking is Internet plumbing, not glitz. I now use Pinboard, and highly recommend it.

---

1. Time for the obligatory disclaimer. Yes, Design is about problem solving, and it includes elements such as User Research, Interaction Design, Content Strategy, Visual Design, etc. Here I am referring only to the aesthetic layer of the Visual Design component. ↩

Marty Cagan argues that splitting the Product Manager and Product Ownership roles into two positions is a mistake:

This approach has two common negative consequences.  The first is that there is no clear owner (neither person takes responsibility for the product), and the second is a common lack of respect or understanding between the two (the “product manager” doesn’t appreciate the technical complexities, and the “product owner” doesn’t appreciate the customer’s pain).

I agree, and I would actually go one step further. I view Product Ownership activities (representing the voice of the customer, interacting with the development team, managing the backlog, etc.) as a subset of the overall strategic Product Management position (product planning, execution, and marketing). I’ve resisted calling my team Product Owners, and prefer to say that they are Product Managers who fulfill a Product Ownership role on Agile projects.

The problem is that splitting these roles into distinct job titles also splits their goals. It’s easy for one to become all about the market, and the other to become all about internal development tasks. Instead, a Product Manager should ultimately take end-to-end responsibility for the development of product solutions that meet user goals and business needs. That’s the job. Managing the backlog and working with developers on specifications are just part of that overall function, not a thing on its own.