Menu

Improve prioritized feature lists by adding more dimensions

Ken Norton wrote a really nice post about the problem with prioritized feature lists in product development, using his team’s early work on Google Docs as an example. Specifically, here is the problem he highlights in Babe Ruth and Feature Lists (Why Prioritized Feature Lists Can Be Poisonous):

Our wish list approach also created false equivalence. There was a huge chasm between what #1 meant to us and what it meant to our users. For us, it was first amongst equals. To them it was a painful tumor overdue for removal.

Orders of magnitude separated #1 from the rest of the list. That urgency didn’t come through until we got a bunch of them in the room and let them vent.

It’s worth reading the whole post before continuing, because the context is important. Ken highlights a really important point about prioritised feature lists — they are too one-dimensional to give you enough confidence about the product development decisions you’re making. That’s why it’s so important to plot priorities on multiple dimensions to aid in decision-making.

The method that springs to mind immediately in the case of the Google Docs example is something I’ve written about before, the Kano model. Ken explains that even though they saw text formatting within Google Docs as an important feature to work on, users saw it as a major frustration, and a fundamental bug that needed to be fixed.

Plotting their list of features using the Kano model could have highlighted this disconnect earlier in the process. To recap, the Kano model, developed in the 1980s by Professor Noriaki Kano for the Japanese automotive industry, is a helpful method to prioritise product features by plotting them on the following 2-dimensional scale:

  • How well a particular user need is being fulfilled by a feature
  • What level of satisfaction the feature will give users

The model is generally used to classify features into three groups:

  • Excitement generators. Delightful, unexpected features that make a product both useful and usable.
  • Performance payoffs. Features that continue to increase satisfaction as improvements are made.
  • Basic expectations. Features that users expect as a given — if these aren’t available in a product, you’re in trouble.

Here is a visual representation of the Kano model:

The Kano Model

Now, let’s take Ken’s original list of prioritised features and plot them on the Kano model. Obviously I don’t have the background that the team would have had, so this is just a guess to illustrate the point:

Kano model for Google Docs

With these added dimensions (and let’s assume there are 10 or more features on this graph), Product Managers can begin to make plans for what they need to work on by always keeping a balance between Basic expectations, Excitement generators, and Performance payoff features.

Now, I’m sure we could quibble about where exactly each feature should be plotted, but it’s immediately clear from this example that Formatting is a Basic expectation that needs to be very well met for Google Docs to get even close to parity with other word processors. That’s where they needed to start, and only once the basic expectations were met, should they have moved on to adding additional features to Formatting. At the same time, working on features like improved Sharing and Commenting would also have shown users that the product continues to get better over time (while generating some much-needed excitement).

So, with that said, I’d like to add a bit of a “yes, and” to Ken’s post. Yes, prioritized feature lists can poisonous, and one way to make sure that doesn’t happen is to add additional dimensions to the list to improve the accuracy of the decision-making. The Kano model is one approach, and I also discuss a couple more in The ultimate product question: How do you know what’s important?

Demo Mode vs. Reality Mode in product development

Rebekah Cox wrote a great post discussing the difference between product Demo Modes (in-store displays, on-stage demos that work without a glitch, picture-perfect product intros) and what she calls Reality Mode:

Reality mode takes time, iteration, data and user research. It takes honestly using what you’ve created and putting it through its paces. It takes asking yourself “is it useful?” and honestly answering. The result may not align with conventional wisdom, you may have to sacrifice that clever hook everyone comments about (but is ultimately useless or worse) and the demo may be boring or nonexistent. But by using your product in the real world and thinking about its true utility and value, you may end up with an enduring product where people are delighted through consistently delivered value instead of just a cool demo.

It reminds me of Marco Arment’s assessment that Facebook Home is “designed for optimal input and failed to consider real-world usage.” This is a very real problem in product development. It takes courage to look your darling project in the eye, find it wanting, and admit to it.

[Sponsor] Fracture. Photos printed on glass.

Fracture prints your photos in vivid color directly on glass. It’s picture, frame & mount, all in one.

It’s a modern, elegant and affordable way to print and display your favorite memories. Your print comes with everything you need to display your photo, right in the durable packaging.

Fractures come in a variety of sizes and prices, starting at just $12, with free shipping on orders of $100 or more.

Fracture prints make great Father’s Day gifts and are the perfect way to fill up empty walls in your new home or apartment. Check it out.

Fracture

Sponsorship by The Syndicate.

Instead of “intuitive”, aim for UIs that are familiar, legible, and evident

John Pavlus wrote a great piece about the phrase “intuitive interfaces”, and comes to the following conclusion in I’m Boycotting “Intuitive” Interfaces:

I think what we all want from technology are interfaces and interactions that feel familiar, legible, and evident. They should teach us in ways we would like to learn, and speak to us in a way we can understand. This doesn’t mean that technology ought never to surprise or challenge us. But desperately seeking “intuitive” feels, to me, like a kind of techno-animism. Interfaces aren’t magic, and we don’t really want them to be. To borrow from Timo Arnall: interfaces are culture. And like any pieces of culture, what they ought to do is simple: they ought to connect. 

Designers and developers: collaboration and empathy required

Lucas Rocha talks about the importance of designers and developers working closely together in Mind the Gap:

Iterative design processes that engage designers and engineers very early tend to result in higher UI quality because it provides the necessary flexibility and agility to steer ideas as they are implemented. Sounds obvious but this is much easier said than done. Just see how rare is to find products with outstanding user interfaces.

This is very true, and the power of small, collaborative teams have been proven time and again. But it’s important to take this further. It’s not just about collaboration, it’s also about empathy. If designers and developers collaborate but they don’t understand each other, you’ll still get nowhere.

The main issue is that designers and developers approach their respective crafts from very different perspectives. Design is about composition — how to put things together so that the whole makes sense. Development is about deconstruction — how to break down the whole into pieces that can be implemented effectively. That creates a disconnect that is difficult to overcome if their isn’t empathy between the two groups.

Thomas Petersen describes the ideal situation really well in Developers are from Mars, Designers from Venus:

They are the developers who can design enough to appreciate what good design can do for their product even if it sometimes means having to deviate from the framework and put a little extra effort into customizing certain functionality. […]

And they are the designers who learn how to think like a programmer when they design and develop an aesthetic that is better suited for deconstruction rather than composition.

So, it’s not just about meeting more often. It’s also about meeting in the middle to accomplish a common goal together.

PS. All of this reminds me of this matrix on how designers, developers, and project managers see themselves and each other in most organizations:

How designers and developers see each other

Image source: Les développeurs, graphistes et chefs de projets

For teens, Facebook is boring. Or a prison. Or something.

Cliff Watson in Teens aren’t abandoning “social.” They’re just using the word correctly:

What is Facebook to most people over the age of 25? It’s a never-ending class reunion mixed with an eternal late-night dorm room gossip session mixed with a nightly check-in on what coworkers are doing after leaving the office. In other words, it’s a place where you go to keep tabs on your friends and acquaintances.

You know what kids call that? School. For kids who still go to school, Facebook is boring. If one of their friends does something amazing or amazingly dumb, they’ll find out within five minutes. If they’re not friends with that person, it will take 15 minutes.

That’s interesting, but very different from the sentiment in two other recent articles on how teens use Facebook. First, from the fascinating and scary What Really Happens On A Teen Girl’s iPhone, in which a teenage girl describes Facebook more like a prison than anything else:

“I’ll wake up in the morning and go on Facebook just … because,” Casey says. “It’s not like I want to or I don’t. I just go on it. I’m, like, forced to. I don’t know why. I need to. Facebook takes up my whole life.” […]

“If you don’t get 100 ‘likes,’ you make other people share it so you get 100,” she explains. “Or else you just get upset. Everyone wants to get the most ‘likes.’ It’s like a popularity contest.”

And then from Slate’s Teenagers Hate Facebook, but They’re Not Logging Off, an article on a recent Pew study on social media usage among teens1:

“I think Facebook can be fun, but also it’s drama central,” one 14-year-old girl said. “On Facebook, people imply things and say things, even just by a ‘like,’ that they wouldn’t say in real life.” Said another, “It’s so competitive to get the most likes [on a Facebook picture]. It’s like your social position.” Ninety-four percent of American teenagers maintain a Facebook profile, but that doesn’t mean they have to like it. “Honestly,” one 15-year-old girl told Pew, “I’m on it constantly but I hate it so much.”

Whether Facebook is boring, a prison, or some bizarre combination of both, it seems that reports of its decline among teens have been a little premature. I don’t think “a trap you can’t escape” is a good way to ensure continued user growth and satisfaction, but that seems to be the position Facebook finds itself in at the moment.

I half-joked this morning (on Facebook, of course) that I’d like to start RealLifeBook, a site where you don’t leave out the ugly pictures and difficult parts of your life. I wonder if that’s part of the problem that makes Facebook feel like a place you hate but can’t leave — it looks like everyone else is always happy, so you can’t be yourself, and you get caught up in this endless cycle of trying to out-happy your friends to get the most likes.

Damn, do we have to rethink a few things about how the web works…


  1. danah boyd also posted some thoughts on the Pew report, and as always it’s very insightful. 

More on the hype, benefits, and dangers of Big Data

When I wrote The hype, benefits, and dangers of Big Data a few months ago I thought it would be my only post about Big Data, and then I’d move on. But 2013 appears to be the year of Big Data, so you can’t turn a corner on the web without bumping into an article about it. Looking at Google Trends, it’s clear that interest is at an all-time high:

So I wanted to point out just a few more articles that range from calling for a more tempered approach to Big Data to an all-out assault on its value and validity. Let’s start with the juicy one…

In A More Thoughtful but No More Convincing View of Big Data Stephen Few reviews the book Big Data: A Revolution That Will Transform How We Live, Work, and Think and uses it as a way to articulate his distaste with the whole thing:

Data exists in a potentially infinite supply. Given this fact, wouldn’t it be wise to determine with great care what we collect, store, retain, and mine for value? To the extent that more people are turning to data for help these days, learning to depend on evidence rather than intuition alone to inform their decisions, should we accept the Big Data campaign as helpful? We can turn people on to data without claiming that something miraculous has changed in the data landscape over the last few years. […]

As data continues to increase in volume, velocity, and variety as it has since the advent of the computer, its potential for wise use increases as well, but only if we refine our ability to separate the signals from the noise. More does not trump better. Without the right data and skills, more will only bury us.

It’s a long article, but very detailed and highly recommended as a well-reasoned counter-argument to the Big Data movement. Others are a little more pragmatic, suggesting that we improve on the promise of Big Data rather than destroy it. In Coffee & Empathy: Why data without a soul is meaningless1 Om Malik states:

What will it take to build emotive-and-empathic data experiences? Less data science and more data art — which, in other words, means that data wranglers have to develop correlations between data much like the human brain finds context. It is actually not about building the fanciest machine, but instead about the ability to ask the human questions. It is not about just being data informed, but being data aware and data intelligent.

It’s important to take this further and say the soul Om talks about needs to come from qualitative methods like ethnography. That’s why I like Dave McColgin’s point in his article How Will Big Data Change Design Research?:

In our field of designing products and experiences, the ‘why’ stays at the center of our process and creativity. Many designers work mostly on new products and services for which there may not yet be reliable data available. […] While Big Data can inform designers on how to improve once they put something out there, it is design research that provides principled guidance towards good solutions all along the way. Big Data can’t help us do that right now.

Tricia Wang’s Big Data Needs Thick Data is another excellent plea for ethnographers to get involved in the Big Data movement, to produce what she calls “Thick Data”:

Big Data produces so much information that it needs something more to bridge and/or reveal knowledge gaps. That’s why ethnographic work holds such enormous value in the era of Big Data. […]

Big Data reveals insights with a particular range of data points, while Thick Data reveals the social context of and connections between data points. Big Data delivers numbers; thick data delivers stories. Big data relies on machine learning; thick data relies on human learning.

And finally, Martin U. Müller and Marcel Rosenbach look at some of the scarier implications of Big Data in Living by the Numbers: Big Data Knows What Your Future Holds:

Is it truly desirable for cultural assets like TV series or music albums to be tailored to our predicted tastes by means of data-driven analyses? What happens to creativity, intuition and the element of surprise in this totally calculated world?

Internet philosopher Evgeny Morozov warns of an impending “tyranny of algorithms” and is fundamentally critical of the ideology behind many current Big Data applications. Morozov argues that because formulas are increasingly being used in finance and, as in the case of Predictive Policing, in police work, they should be regularly reviewed by independent, qualified auditors — if only to prevent discrimination and abuses of power.

I personally think there is the same value in data that there has always been, and that the Big Data movement isn’t so much about the size of the data sets, but the ability to extract more of that inherent value (signal) from the noise. But an algorithm will only take you so far. As always, knowing what and how much is not very useful without knowing why. And Big Data will never be able to tell us why…


  1. What’s that? You think I’ll just automatically link to any article with the word “coffee” in the headline? I resent that accusation, sir or madam! 

[Sponsor] Igloo: an intranet you’ll actually like

My thanks to Igloo for sponsoring Elezea’s RSS feed this week.

Igloo has some funny new Sandwich videos to lighten your day (and maybe convince your boss and/or IT to upgrade your intranet to something more human). Check them out:

(You can also get a free 30-day trial and bring back Cake Fridays here.)

Igloo

Sponsorship by The Syndicate.

More

  1. 1
  2. ...
  3. 126
  4. 127
  5. 128
  6. 129
  7. 130
  8. ...
  9. 201