Earlier this week I was struggling, as usual, to navigate my way around our Web Analytics provider, Omniture (SiteCatalyst in particular).  Specifically, I once again had to hover over every single icon in one of the views to figure out what they mean.  I was looking for a specific menu item called “Add Metrics,” which ended up not being an icon at all, but rather a text link.

Anyway, in frustration I tweeted this screen shot, and implied that if your icons require users to hover over them to figure out what they mean, you’re dong it wrong:

To their credit and my surprise, quite a few people at Omniture follow mentions of the company on Twitter, so pretty soon I got this comment on the post from one of the Product Managers at Ominture:

Hi Rian - this is great feedback you have given us. We are taking steps to address your specific point in an upcoming release of SiteCatalyst. The icons will be clearer, and tool tips will not be necessary.

But not everyone was happy.  I also received this reply from @RRS_ATL:

We moved the conversation to email, and Rudi is a really nice guy — we had a very healthy debate about the issue.  I wanted to spend a little time here to summarize my thoughts on this particular issue and icon design in general.

First, let me say that I am not against tool tips and alt text when they provide additional context for text where space is limited, or more information about an element on the page. My specific issue with the Omniture icons is that they are not easily recognizable and mapped to what they actually do.  That breaks an essential UI rule which states there needs to be a match between the system and the real world:

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. (from Nielsen’s 10 Usability Heuristics)

For example, as you can see in the photo above, the Omniture icon for “link to this report”  has a chart and an arrow in it - that’s simply not intuitive enough.

What I am proposing in the Omniture case is one of two solutions:

1. Redesign the icons to be more intuitive (which, from the PM’s comment on my post, is what they’re doing), or
2. Turn them into text links (because what’s the use of icons if you have to use text to explain them?)

Icon design is hard, and I think it defeats the purpose if your icons are not easily understandable.  In a great post on UX Magazine called Realism in UI design they discuss this issue in depth, and explain why it is so hard to get right:

People are confused by symbols if they have too many or too few details. They will recognize UI elements which are somewhere in the middle.

The trick is to figure out which details help users identify the UI element, and which details distract from its intended meaning. Some details help users figure out what they’re looking at and how they can interact with it; other details distract from the idea you’re trying to convey. They turn your interface element from a concept into a specific thing. Thus, if an interface element is too distinct from its real-life counterpart, it becomes too hard to recognize. On the other hand, if it is too realistic, people are unable to figure out that you’re trying to communicate an idea, and what idea that might be.

This only scratches the surface of icon design, so for more interesting reading on the topic, see:

• 10 Mistakes in Icon Design
• 7 Principles of Effective Icon Design
• And for those who like their design mixed in with a little Science, there’s the excellent Icon Analysis from Boxes & Arrows.

To summarize, I stand by my view that if you have to hover over every single icon to see what it means, you either have to design better icons, or just use text.  But I’m open to counter-arguments for sure… What do you think?

This is the third post in a series I recently started on software development and the role of the Product Manager.  If you haven’t already done so, it might be a good idea to read Part 1 (Overview) and Part 2 (How to ensure that product requirements are informed by user needs) before your read on.  This post continues the discussion on Product Requirements and the different sources that should feed into requirements.

In Part 2 of this series I discussed the role of user needs in product requirements, and in this article I’d like to talk about the role of business needs and technology needs, and making sure that the right balance is struck when incorporating these (often loud, often conflicting) voices in the organization into what gets built.  So, let’s dive in…

Business needs

When I was at eBay, we often heard the mantra from our executive team, “If you fix the user experience, you fix the business.”  Lovely words, but when it comes time to decide what to build, “Fix the business” usually comes first.  This is, of course, not a bad thing, but unfortunately the best user experience often means taking revenue-generating features out of the product.  Would we have banner ads if UX really was king?  Don’t think so…

Still, you have to make money.  That is, after all, the point of the business.  The trick is to understand the difference between good revenue streams and bad revenue streams, and opt for the good ones as much as possible.  A good case study on this is eBay’s interesting approach to photos in product listings on the site.  eBay started charging users to add photos to their  listings pretty much from the very beginning.  This was back in 1995, and in those days storage wasn’t dirt cheap, so it was a natural thing to do.

As the years went by, and more and more photo sharing services popped up that allows users to upload and stores pictures for free, this approach became increasingly frustrating for users.  The other side of the story is that it’s actually in eBay’s best interest for users to upload photos of their items — items with photos convert way better than those without photos.

Still, it took many months to convince the executive team to make it free for users to upload photos of their items.  This is an example of a bad revenue stream — it brings in money, but to the detriment of users and the overall success of the business.  When it comes to adding revenue streams to your product, the important question should always be: are you doing this so people will buy it, or are you doing this so people will want to use it and be willing to pay for it****?

In a recent interview on Microsoft and tablets, Steve Ballmer said the following:

And so we are working with [our] partners, not just to deliver something, but to deliver products that people really want to go buy.

And in that lies the core of what’s wrong with Microsoft — the difference between making products users want to buy vs. making products they want to use.  When you make products people want to use, charging for the value it brings (i.e., looking for good revenue streams), becomes so much easier.  Approaching it from the more negative side, I guess you could also say it like this:

Technology needs

One of the dangers of product roadmaps and the PM’s role is that back-end maintenance and optimization can start to take a back seat.  This is a huge mistake, best explained through the metaphor of technical debt. In Steve McConnel’s great post on this topic, he defines technical debt as follows:

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. “If we don’t get this release done on time, there won’t be a next release” is a common refrain””and often a compelling one.

He goes on to explain why this can become a problem:

If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., “servicing the debt”) that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the “debt ratio,” which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.

Technical debt isn’t always wrong — quick hacks to get a product out the door is often the right choice.  But as with most debt, it’s important to start paying it off in small chunks as soon as it’s incurred, before you get into too much trouble.  If you’re interested in this topic, also read Andrew Chen’s great post called Product Design debt vs. Technical Debt.

Striking the right balance

Now that we’ve discussed user needs, business needs, and technology needs, the obvious question is: how do you decide what to build now vs. later vs. not at all?

For that, the right answer is unfortunately, in my experience, the traditional cop-out answer: it depends. It depends mainly on the following factors (in no particular order):

• The level of user engagement and involvement.  If users are screaming for a particular feature, or if there are rumblings around “why haven’t you done anything for us recently?”, it could be a good time to up the level of customer needs you meet.
• The stage of the product in its lifecycle. If the product is just at the beginning, customer needs will most likely come first.  As the product matures, technology and business needs become more important and should start taking precedence.
• The financial state of the business.  If there are ways to add good revenue streams, those opportunities should always be taken.

Depending on where the business is on each of these 3 factors, the different inputs might be weighted differently. If the product is going through a growth spurt with lots of buzz, more attention could be placed on user needs. If the product is mature and making good money, technical needs might get more weight.

Exactly how this is balanced in each version/release of the product has no clear answer, and it’s where the art of product management comes in. But one thing is for sure — none of these needs can be ignored for any extended period of time. Take too long to pay down technical debt, and your platform will become bloated and unable to scale. Focus on making money too much, and users will fall out of love with your product.

Successful products have clear product management leaders who are able to take all the different requirements inputs, place it into context with other external and internal pressures, limits, and opportunities, and design a product vision and a (flexible) product roadmap that ultimately increases product/market fit (which I mentioned briefly in Part 2 of this series).

But what do product requirements look like, and what is the Product Manager’s role in that process?  That will be the topic of the next post…

I recently started a series on software development and the role of the Product Manager.  If you haven’t already done so, it might be a good idea to read Part 1 (Overview) before continuing.  In this post I’d like to write about the first step in the development process, namely Product Requirements, and the various sources of input that go into deciding what to build and how to improve your product.

As I started writing I realized the topic is just too big for one post, so I’m going to split it up into a few different posts:

• Part 2 (this post) will be about user needs as an input to product requirements.
• Part 3 will be about business needs and technology needs as inputs to product requirements.
• Part 4 will be about  the PM’s role in the Product Requirements phase.

Even though the focus here is not on what kind of product/service your company should develop and sell, I do want to briefly mention product/market fit, because it is probably the most important aspect to figure out to be a successful business.  No one talks about this better than Marc Andreesen, so I wanted to quote from one of his (now deleted) blog posts:

The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have?

The size of a startup’s market is the the number, and growth rate, of those customers or users for that product.

The only thing that matters is getting to product/market fit.  Product/market fit means being in a good market with a product that can satisfy that market.

With product/market fit figured out (no easy task), and a workable product to start with, it’s time to get serious about building and improving the product — and that’s the stage where this post starts.  At the heart of a good product roadmap stands a Product Manager that is able to strike a balance between user needs, business needs, and technology needs.  So let’s look at each of those in detail, starting with user needs.

User needs

Identifying user needs is at the core of a user-centered design process, and it involves gathering feedback from the users of your product through a variety of methods to uncover unmet needs and opportunities for improvements.  This is called user experience research (UER), and there are plenty of resources available on the topic, so I’m just going to provide an overview here.

First, it’s important to mention the fundamental difference between market research and user experience research:

• Market research seeks to understand the needs of the market in general, and is generally more focused on areas like market fit, brand perception, advertising and pricing research, and ways to uncover perceptions of the company and its products.
• In contrast, user experience research focuses on users’ interaction with the product.  It relies heavily on observational techniques, since users are notoriously bad at describing their experiences or predicting their behavior.

There are many ways to classify different UER methodologies, but my preference is for a classification that lines up the different methods with the outcomes required by different phases of the product development process.  In that approach, there are three classes:

1. Strategic research

Strategic research is done with the goal of coming up with new product ideas and business opportunities, or preliminary design explorations during the product discovery phase to  help with the brainstorming of design solutions.  Here are some of the methods that fall into this class:

• Ethnography.  A technique long used in Anthropology that has only recently found its way into the toolkit for research on interactive products.  It involves going to users’ homes or offices, and observing how they use your products in their natural environment.  It allows the researcher to see users in action where they feel most comfortable.  Ethnography is all about observing and listening.  It is generally not task-based like usability studies, but follows a loose interview script with the goal of uncovering needs and insights that users are unable to articulate.  I have an extreme positive bias towards ethnographic research, especially in contrast to focus groups (of which I’m not a fan at all, but that’s a subject for a different post).  I have seen first-hand how ethnography sparks innovation when it shows how users make up their own workarounds for the limitations of software, which in turn reveals opportunities for product improvements.  When it comes to exploratory methods to help with product strategy and roadmaps, there simple is nothing better than a good ethnography study.
• Participatory design.  Another favorite, this technique brings users together to solve design problems in a way that would make sense to them.  The purpose is not to take users’ designs and implement them, but to find out which elements and activities are most important to them.  My preference is to do this in diads, where 2 users work together on a design.  This forces both participants to be active, and you learn as much from their conversation with each other as with the designs they put together.  The usual process is to provide users with a blank page or basic framework, cut-outs of various elements that could go on a page, and watch and listen as they make trade-offs and design decisions on what should go on the page based on how they would use the product.  This technique especially helps guide interaction design because it gives a glimpse into users’ process as they go through the site.
• Concept testing.  This is a good way to gather feedback on an approach before wireframes or mockups are created.  Storyboards/comics are great artifacts to use for this kind of testing, since it takes design out of the process, and gathers feedback from users on the process you intend to design.  Although mostly done in-person with 6-8 users, there are also great tools for large-scale concept testing, like Invoke.  Below is an example of a storyboard one of our researchers at eBay used during early concept testing for one of our products:

Further reading on strategic research:

• Ethnography in Industry: Objectives?
• How to set up and run participatory design sessions, analyze data and present results effectively

2. Design research

Design research includes most of the methods that are associated with traditional user experience research.  Its role is to improve and refine existing designs in various levels of fidelity.  Some of the methods include:

• Usability testing.  This is, of course, the most well-known UER method, and what most people default to for any kind of design feedback.  Task-based usability testing in a lab is a fantastic tool, but it has become a little bit too much of a “when all you have is a hammer…” method.  Usability testing should be used to uncover usability problems with a proposed interaction design.  It should not be used for feedback on visuals, finding out which design users prefer, or uncovering new product ideas.  There are other techniques that are much better suited to that task.  Usability testing involves 1-on-1 sessions with users where the researcher observes them as they perform assigned tasks.  This kind of direct observation is a great way to understand what users would actually do on the site (as opposed to what they say they would do), as well as to uncover the reasons why they do what they do.
• RITE testing.  Rapid Iterative Testing & Evaluation (RITE) is a very specific form of usability testing, but I wanted to call it out because it is my preferred way of testing.  It involves a day or two of focused usability testing, followed by a design cycle where the feedback is immediately injected into the design before the next round of testing.  Doing several of these cycles quickly means your outcome isn’t a bloated Powerpoint deck with a bunch of recommendations; your outcome is a better design that incorporated user feedback in real time.  As the debate continues on how UX can be more involved in Agile development, this technique should become increasingly important since it fits in perfectly with the Agile mindset.
• Desirability studies.  Invented by researchers at Microsoft (yes, really - see this Word article where they outline the approach), this has become another favorite technique for me if I want feedback on the visual aspects of a site (not so much interaction), and specifically which visual approach users like more when there is more than one alternative.  It involves a survey to a large number of users where they are asked to rate one of the proposed design alternatives using a semantic differential scale.  The survey is done as a between-subjects experiment, meaning each user sees only one of the proposed designs, so that they are not influenced but the other design alternatives.  The analysis then clearly shows differences in the visual desirability of the proposed design alternatives.

Further reading on design research:

• Complete beginner’s guide to design research
• Usability testing overview
• Do’s and Don’ts of usability testing

3. Assessment research

Often neglected, the role of assessment research is to measure the impact design decisions have made, and to evaluate success and continued areas that need improvement.  This requires larger sample sizes to ensure the ability to compare before/after metrics with statistical significance, so these methods are mainly quantitative in nature.  Methods include:

• Product surveys.  Everyone hates surveys, but it remains an effective way to assess how design changes are affecting user perceptions of the site. Different from most market research surveys you receive (and delete) in your inbox, these surveys deal specifically with user perceptions of the interaction and design.  It’s not always effective as standalone research studies since there is so much bias in surveys with their <5% response rates, but if you can run surveys over time, and control the sample so that the bias remains the same, it can be a very good tool to ascertain the success of your design changes.
• Online user experience assessments.  Another favorite, tools like Keynote allows you to gather real-time click-through data as well as subjective user feedback.  It uses a proxy or a browser download to give users tasks on a site, and ask them questions about the experience while their activity is being tracked.  This often produces a mountain of data, which can be quite overwhelming and not always effectively used if there is not enough time/resources available to analyze the data.
• Analytics.  Web analytics need no introduction, but there are several tools specifically aimed at user experience, with my favorite being Razorfish’s Advanced Optimization tool for web forms.  By placing a small piece of JS on form pages, it gives you a mountain of data on how users interact with forms, including what error messages they receive, how much time they spend in each field, the last field they were on before closing the form, scrolling data, and the list goes on.  It’s a great way to improve form conversion.  I honestly don’t know why they don’t market this thing more.

So that’s an overview of user research methods — there are many more, but I wanted to focus on the ones I’ve found especially useful in my own work.  The real power of user research starts to happen when you combine methods and triangulate results to come up with a product strategy that takes a variety of quantitative and qualitative insights into consideration.  If you’re interested to learn more about this, Using Multiple Data Sources and Insights to Aid Design is a good post on the topic.

There are so many resources available on user research — your best bet to stay on top of the latest happenings in the field is to subscribe to UX Booth and UX Matters.

In part 2b, I’ll talk about the other two inputs to Product Requirements: Business Needs and Technology Needs.  I’ll also discuss how all of this fits into creating Product Requirements, and what the Product Manager’s role is in all of it.  Stay tuned!

This week I was in Johannesburg for the debut of Tech4Africa, a conference about web technology in the African context. It was a fantastic experience, an opportunity to learn from and meet some great people, and I will most certainly be back next year (but hey, Gareth, let’s move it to Cape Town next year!). Yes, there were the usual small conference hiccups, but nothing that can overshadow the importance and significance of this event.

The mere fact that we were able to listen to speakers like Clay Shirky, Andy Budd, and John Resig, as well as some top South African thinkers & doers, and discuss with them the uniquely challenging opportunities that exist here in Africa, made this conference a winner. The content was mostly great, but the conference was more than that — it was about being inspired and energized about being in this industry, at this time, in Africa. You should follow Tech4Africa and its head organizer, Gareth Knight, for updates on the conference. And no matter where you live, you should attend next year. This event is here to stay.

I also had the great opportunity to speak on a web design panel with Allan Kent, Basheera Khan, and Mike Lewis. We took a User-Centered Design (UCD) approach to redesigning Payfine.co.za, a web site that allows South Africans to pay the many traffic fines they get every… well… every month or so.

We’ve never met each other before the conference, and we were all in different locations. So, since we had to do this remotely and in our limited spare time, we broke the process up into three distinct user experience elements and each took responsibility for one of the tasks: content strategy (me), interaction design (Bash), and visual design (Mike). We collaborated a lot along the way, but we decided to each lead the creation of one piece of the puzzle, and then put it all together in a coherent story (this was Allan’s job!).

The end result? Well, you should judge for yourself. Here is what Payfine currently looks like:

And this is the proposed redesign:

The one thought I want to pull out above the rest about this process, is that UCD is not rocket science. It’s not easy, but it’s not rocket science. There is a process, and there are rules (they can be broken, but they help focus the design process).

But. It does require a mind shift (I hate that word — can anyone suggest something different?) in the African web space — a realization that the interfaces we currently have on our banking sites, our e-commerce sites — even our entertainment sites — are simply not good enough. And it requires a commitment by those companies to invest in the user experience of their sites, because it will have a positive effect on the business.

Below are the slides we went through during our session, which I amended to make it a little bit easier to read without the voice-over we provided. We’re all happy to answer any follow-up comments or questions on this, so please let us know if you have any. And I really want to thank the rest of the team — this has been a great experience — let’s do it again!

How we redesigned Payfine.co.za - Tech4Africa

In one of his characteristically brilliant essays, Paul Graham recently wrote:

I think most people have one top idea in their mind at any given time. That’s the idea their thoughts will drift toward when they’re allowed to drift freely. And this idea will thus tend to get all the benefit of that type of thinking, while others are starved of it. Which means it’s a disaster to let the wrong idea become the top one in your mind.

The importance of focus in a startup, or any other business for that matter, is such a basic principle that no one disagrees with it, but it is still such a difficult thing to get right.  One of the reasons is that you don’t want to stifle innovation, and some of the best ideas can come from a completely random project you went off to do in your spare time.

Whatever your feelings are about side projects that take you off your main focus, it is important to recognize them for what they are: distractions.  This doesn’t necessarily mean it’s bad, but let’s call it what it is — these projects distract you from your “top idea.”

For the products I’m responsible for at Yola, we have name for such distractions.  We call them “squirrel projects.”  If you’ve seen the movie Up, you’ll probably immediately know what I’m talking about.  If not, here’s a refresher:

I don’t think “squirrel projects” need more definition than that video…  So, when one of your team members go off on a sometimes-random-but-always-guaranteed-to-be-cool tangent, it’s important to do two things:

• Call it out as a squirrel project
• Determine whether or not it’s a squirrel worth hunting

Figuring out if it’s a squirrel worth hunting depends mainly on:

• The timing of the project
• The potential value of the idea

I’d say that 2 days before release day is a pretty bad time to go squirrel hunting.  But what if you’re in the beginning of a sprint and something great comes along?  Adjust.  Reprioritize. Throw some things on the backlog, and make room.  Because sometimes, it’s worth it.

It’s also important to note that “value” doesn’t necessarily mean immediate ROI.  There are different ways to get value out of a squirrel project.  Sometimes it’s the potential for revenue down the road.  Sometimes it’s the time spent now on automation tasks that will save you a bunch of time later.  And sometimes, it’s just plain cool (two words and a hint for something you should try on Yola: Konami Code).

Squirrel projects aren’t bad.  But they can be devastating to your focus and momentum if they happen at the wrong time, and/or they have no potential for value.  So go hunt the good ones, and let the bad ones go.

Almost a year ago I wrote a post to propose/summarize a universal model for product development.  I’ve now refined that model into what I believe is much closer to what the original intention was: a product development framework that is detailed enough to be practically usable, but generic enough to fit on top of any development paradigm (Agile, Waterfall, etc.).

I’ve decided to start a series of posts on software development and the Product Manager’s role in that process.  The first, this one, is a very general overview — it’s basic, yes, but necessary to lay the groundwork.  After that, I want to spend time writing down my thoughts on each of these stages in detail.

Why do this? Because I think the Product Management profession is finally starting to come into its own, and I’m hoping that through discussion we can, together, evolve a practical guide to what we do from day to day, something that is both flexible enough and rigid enough to be helpful without being constricting.  And maybe also just to force myself to think through this in detail and become more deliberate and focused on each of these steps.  I hope you’ll join the discussion!

I won’t be talking about scheduling, scrum methodology, or team organization in these posts.  The goal is to focus on the work that needs to be done — whether it’s being done by an individual or a core team is not the focus here, and will be different depending on the company, the philosophy, and the team.

So let’s start here — a diagram of a proposed universal model for software product development:

Borrowing from and expanding on my original post, I want to make a few observations. First, there are a few assumptions that are important to note about this model:

• Regardless of the development methodology, representatives from Product, Marketing, Business, Design, and Engineering should be involved to some extent from the very beginning of the process. Once detailed requirements are being written, it largely becomes an Engineering and Product effort to ensure momentum and avoid the dangers of design by committee, best summed up by Dilbert:

• Having said that, it is important for one person to own this process (i.e. be accountable for its success) from start to finish, and that person should be the Product Manager/Product Owner. A good product manager is not a dictator. He/she is a facilitator between all the different stakeholders of a product, and the really good ones are able to get through this model on time and on budget, every time and with as much consensus between groups as possible.
• The roles of the Responsible (R), Supporter (S), and Informed (I) are important to define for each of these steps.  Most important is that there should be only one “R” for each step.  This doesn’t necessarily mean it’s the person who does all the work, but it’s the person who is ultimately responsible to get the work done (with help from the “S”es).
• This model is designed to work for any organizational structure, project size, and timeline. If the project is large, more time can be spent on each step. If the project has a tight timeline, it doesn’t mean that you will skip the “Iterate” part of “Design + Iterate.” It just means that you will spend less time on it (more on that later).

Summary of the different aspects of the model

The rest of this series will be devoted to detailed discussions about this model. My goal with this post is to be general and make one or two points about each aspect. So let’s look at some definitions and implications of the model:

• The starting point - identifying needs. At the beginning of any project (new or iterative), it is important to gather and synthesize input from three different sources:
  • User needs. Everyone needs to have a good understand of the market, the target segments, and their behaviors and attitudes. There’s not enough room to go into detail here, but it is important to look at four sources of user input: market research (segmentation, etc.), user experience research (usability studies, ethnographic explorations), site analytics (behavioral analysis), and customer support (call transcripts, interviews with CS reps, etc.). Having this common understanding allows the organization to build products that matter to users.
  • Business needs. User experience practitioners too often neglect the fact that well, your site has to make money! Revenue goals are not a good excuse for bad design, and that attainable revenue goals are essential to push the organization to design good product.
  • Technology needs. Engineering needs to be at the table from the start. They know the limitations of the product, they know what needs to be fixed, they know what technical debt needs to be paid down. Having engineering and product working together is essential in good product development.
• Requirements gathering. Pragmatic Marketing, in a post entitled “On Reqs and Specs: The Roles and Behaviors for Effective Product Definition,” proposes some solid definitions for the three different documentation outcomes in this model: Requirements, Functional specifications, and Technical specifications. The first outcome from the discussion and synthesis of needs is a common understanding of the problem statement you are trying to address, which takes the form of Requirements. A requirement is simply a short statement of the problem, and Pragmatic Marketing recommends the following format: “Our preference is the Requirements That Work format: [Persona] has [problem] with [frequency]. It forces product managers to explore the problem, not the solution, and helps the design team understand the context of the problem.”
• Solution brainstorming. Once the problem has been defined and agreed upon, the team starts thinking about solutions, usually through some form of design thinking or abductive reasoning. There are three important aspects of this phase, which is often called Product Discovery:
  • Start with blue sky ideation (divergent thinking). At this point, don’t limit solutions by what is technically or otherwise feasible. Spend time dreaming about the product - this is where innovation happens!
  • Relentlessly prioritize (convergent thinking). This is the part of the process where nonsensical ideas are thrown out, and the team consolidates around a few possible solutions to the problem that can be further explored. Remember: there is no commitment to implementation or specific designs yet at this phase.
  • Apply the technology filter only after the ideation phase. There is a very important technology filter that needs to be applied during prioritization. What is technically feasible? If something is currently not feasible, what would it cost to build the right architecture? Those early inputs can save a lot of headache down the road.
• Flow charting and wireframing. This phase starts to put some flesh around the second output document, Functional specifications, which Joel Spolsky defines as follows: “A functional specification describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.” At this point visual design is still left out of the picture, all you are doing is defining flows and interactions.
• High-fidelity mockups. In this phase, visual design gets involved to design the experience as it will look on the screen.  If there are pre-defined patterns and standards (as is hopefully this case), this could be a pretty light step, but I do believe it is important, even in an agile environment, not to leave this part up to chance.
• Technical specifications. Development can start before the full designs have been completed.  Once the flow and interaction are sorted out, you do in most cases have enough information to start task breakdown and implementation.  Quoting Joel Spolsky again, “A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.”
• Build, discuss, iterate. Everyone designs a product, but it is sad to see that when time/budget gets tight, iterating on it before it goes live is often the first part of the process to fly out the window. It cannot be overstated how important it is to prototype and test your designs before they go live. And not having time is really no excuse. If you have no time, make a paper prototype and test it with three of your friends over coffee in the evening. You’d be surprised how much value this can add. Boxes and Arrows has a great article on prototyping and how to integrate it with your design process that’s well worth the read.
• QA, release, assess. After the thrill of releasing, the assessment phase is extremely important and often overlooked. It is important to define your measures of success upfront, and then follow up to see if you’ve met those goals. How do users respond to the product? Are we meeting revenue/engagement goals? What can we learn from how users interact with the product to give us ideas for new products? I’m also an advocate for using the same four sources of input we discussed earlier (market research, user experience research, site analytics, and customer support), as opposed to relying on only one methodology, like a 3-week A/B test. More on the dangers of that in one of my earlier posts.

Where we go from here

So now that the stage is set, what happens next?  Over the next weeks and months, I’d like to write a detailed post on each of these phases, particularly from a Product Management perspective, and what the role of the PM/PO is during each of the phases.

There are, of course, lots of resources out there for Product Managers, but I’m hoping to talk more practice than theory here, and hopefully generate some discussion (and disagreements!) to help us reflect on our chosen profession.

PS Big hat tip to @justinspratt who gave me the nudge I needed to start this series.  He is the real deal, despite being Australian.

“DStv: so much more user-friendly,” says the ad in the background as I try in vain to press the button on the remote control just right so I can pause my show and go get another cup of coffee. It probably has something to do with last straws and camels and stuff, but that ad finally put me over the edge and onto the computer to write about the user experience of DStv’s remote control for their HD PVRs.

It is often much easier to figure out which companies practice user-centered design and which don’t when they produce physical products as opposed to online interactions. Think about Target’s redesign of the prescription drug bottle as an example of deliberate design, and America’s 1040 Tax form as an example of what happens when there is little to no design input on a product.

In the past I’ve had the pleasure of using the Logitech Harmony 880 universal remote, pictured below beside the DStv remote, and that showed me that it is, in fact, possible to design a remote that even my mom can use. So I’d like to write about the differences between DStv’s remote for the HD PVR’s, and the Logitech Harmony 880 universal remote. Both are shown below:

DStv HD PVR remote

Logitech Harmony 880 remote

The DStv remote - Why it’s bad

The DStv remote control breaks many principles of user interface design, but mainly this one: Recognition rather than recall. To quote Jakob Nielsen:

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

The principle applies mainly to online design, but it can be applied to the DStv remote in the following ways:

• Several buttons have no proper affordance and mean nothing to the user. There are 5 different-colored buttons with no mapping to the real world, and some labels are confusing. As examples of interactions that are not obvious to the user without either reading the manual or extensive trial-and-error:
  • To view your recorded shows, you have to press the red button.  How am I supposed to know that?
  • To make matters worse, once you see a list of your shows, this same red button is used to delete the show.  And that’s how we lost the latest episode of 30 Rock.
  • To edit certain (but not all) settings, you have to press the white button within the menu system.
  • At other times, the white button is used to edit your favourite channels.
  • When you pause or rewind a show, you go back to live TV by pressing the “TV” button.
  • The “up” button brings up your favorite channels, while the other direction buttons bring up all available channels.
• Several buttons don’t do anything at all. I haven’t seen the blue, yellow, and green buttons used for anything. It’s not uncommon for remote control buttons to be “reserved for future use,” but I maintain that this is a bad idea because it just introduces unnecessary user complexity.

In addition to that, the play/pause/forward/rewind interaction is awkward. To pause live TV, you have to press the button exactly in the middle, otherwise you might actually start rewinding or forwarding.

Making the fast forward action a pull action instead of a button you press might sound like a good idea, but doing that limits its function. Now you can only fast forward on one speed. If this becomes a push-button, or something other than “hold to fast forward”, you’d be able to fast forward at different speeds.

And this is only the remote… once you get to the on-screen experience the interaction reaches a whole new level of “what the…!?” Maybe we can dig into that at another time. But first, here’s how it should be done:

The Logitech Harmony 880 remote - Why it’s good

• Beautiful, ergonomic design that makes you actually want to use it and not hide it under a pillow.
• Progressive disclosure of features — depending on your activity the “soft keys” at the top of the remote perform different functions, with clear language on the display to indicate which button does what.
• Online programming of the device — no need to remember device codes to set up the features for each component.
• Thoughtful key layout with no ambiguity about which button does what.
• Several smart features, like starting the backlight when you lift the remote off the table.
• User language incorporated throughout — simple commands such as “Activities” and “Watch a DVD” instead of technical references.

It’s clear that Logitech did some user research to find out what the underlying user needs were before they developed this product. A lot of the features can be directly linked backed to complaints I’m sure we all have about remote controls. A couple of examples:

• “I can never see the buttons on the remote when it’s dark in the room, but I also don’t want the light from the remote to disturb my viewing.” Solution: motion sensors that turn on the backlight when you pick up the remote, and turns it off after it’s been sitting still for a while.
• “I don’t want to have to struggle with device numbers and complex remote programming”. Solution: build an online interface where the user can program the remote, and then send the commands to the remote through a USB connection.

There’s probably more to say, and yes a lot of arguments to be made for why DStv’s remote isn’t that good. But in today’s user-centered world, there shouldn’t be excuses any more. Companies need to make products that are useful and usable so that people can enjoy them without frustration. Good user experience = good business.

I do want to end on a positive note and say that I think the DStv iPhone app is a solid piece of user-centered design.  It doesn’t go overboard on features, and it keeps focused on the one thing users need it for — checking TV schedules.  I just think the app designer needs to take a look at the remotes, that’s all.

I’ve been thinking about Evernote and Dropbox, and the characteristics that make them successful freemium businesses.  Of course, a lot has been said about freemium, and Ning’s recent decision to drop that business model has placed it under renewed scrutiny.  But I don’t think it’s time to bury freemium just yet.  I wanted to write down some quick thoughts on what I believe are three essential characteristics of a successful freemium business:

1. Be patient with users.  Evernote’s cohort analysis shows that initial conversion rates are at about 1%, but once users have been with the service for 18+ months, that jumps to 4% — more than enough to be profitable.  And it’s not actually a bad thing to have free users for that long — at that point they are so invested that they’re not going to take their data elsewhere.  They know and love the product, so when they hit the storage limit, they’re comfortable with paying.
2. Have a natural (and inevitable) path to upgrading.  With both Dropbox and Evernote, if you use the product long enough, you’re going to have to upgrade — at some point you’re going to run out of storage.  If you don’t have a natural path to upgrading you need to create one, or you’ll find yourself in trouble.  Users will use your free product for forever and be happy with it.  You need to make it inevitable that a certain % users will hit one of your limits.
3. Have a great free product.  It might sound contradictory, but if your free product sucks, the switching cost will be very low.  Dropbox and Evernote are successful because users love the free product, so when they run up against the limits, the decision to pay is an easy one.

To put it another way, I think that to be successful as a freemium company you need to (1) have a free product that users love, (2) be ok if those users don’t convert to paying customers for months, but (3) make it inevitable that at some point, they will have to upgrade if they want to keep using your service.

If you haven’t seen these great talks on freemium, I highly recommend you invest the time to watch it - very informative:

• Dropbox CEO on Startup lessons learned
• Evernote’s CEO discusses how to make freemium work

I read quite a few excellent UX/PM posts this week, and wanted to make sure you don’t miss out.  So here are some excerpts from my favorite posts of the week.

User Experience Design in the Agile context

In Agile UX and The One Change That Changes Everything, Anders Ramsy writes about how user experience design can be adopted to fit the agile mold a little better.  He calls for less design up-front to basically embrace the MVP approach instead of fighting it:

The first and probably most fundamental change to flow out of starting to build earlier is that of chopping your up-front design phase down to a fraction of what it might be in a traditional model to allow for establishing a foundation of working software, and then evolving the rest of the product on top of that foundation. In other words, we go from Big Design Up Front to Just Enough Design Up Front.

The rest of the post is devoted to how to do that, including thoughts on lighter, conversation-centered documentation, and the importance of collaborative design.

Enough with the “chicken & pig” story

Speaking of Agile, David Bland wrote an impassioned post arguing that Our Divisive Scrum Terminology Needs to be Deprecated:

Scrum teams succeed or fail as a, well, a team.

If the Product Owner is confused about the role or not living up to expectations, it is the ScrumMaster who should be helping them along the way. If the ScrumMaster is failing at coaching up the Product Owner on the framework, then wouldn’t the ScrumMaster be to blame? But wait, since the team has appointed the ScrumMaster, would they not have failed by choosing one who is incompetent?

W’ll just run in circles pointing fingers because there is no easy answer, and using the Product Owner as the scape goat does nothing to help resolve the situation.

Measurement-driven Product Management

The always brilliant Pragmatic Marketing has a post entitled Measurement-Driven Product Management that should make all of us a little uncomfortable.  But good uncomfortable.  Getting better at your job uncomfortable.  Read the post for details on the proposed ways to measure the success of PM, but this is why they make the case for it:

The long term benefit of Product Management becoming measurement-driven is higher team performance, improved predictability and increased credibility. The ultimate benefit is developing the ability to reliably create outstanding products and market breakthroughs.

Can Product Management operate with this high level of maturity, using a reliable measurements and metrics system with more predictable results in a company?

This “holy grail” of product management performance is doable, but often many cultural and process gaps must be addressed first. An organization fosters a measurement-driven culture by reinforcing other aspects of the process, such as tightly coupling rewards, recognition, compensation and promotion to attainment of operational results. Does yours?

Research and Design, sitting in a tree…

In The product of a healthy relationship, Paul Golden discusses the sometimes rocky relationship between researchers and designers:

Hana Thomas of design consultancy Smallfry agrees that while market research can play a crucial role in product design and development, there are dangers. “There can be an over-reliance on market research, which leads to it being used either as a scapegoat for poor decisions or employed too soon in the creative process, stopping ideas in their tracks before they have even had the chance to be realised.”

Thomas refers to the value of ethnographic research to her company’s work in product development and describes studying people in their own environment, under a relevant context, as the “ideal way” to truly unearth latent needs and desires.

According to Reon Brand, the responsive and listening brand that engages its audiences in the creative process as well as in dialogue has a major advantage in our increasingly social-media driven world. However, all research methodologies have their limitations. While consumers can react to what exists and relate back to what they know, some of the designers surveyed by the Design Council felt that consumers were less able to contribute to the development of completely new product or service concepts for the future.

I just became the mayor of someplace you’ve never heard of

On a slightly different note, I found this RWW called Why We Check In: The Reasons People Use Location-Based Social Networks very interesting.  It presents some research on why we use services like Foursquare and Gowalla, and there are definitely some surprises, like using it to keep track of history:

The thing that surprised me most when I asked people why they use location-based social networks is how many of them say they use it primarily to track their own personal history. It’s a lazy diary, people say.  Some people say they use it to help with their expense tracking on business travels.

Happy reading!

I just read an interesting New York Times article on “social reading” (Yes, People Still Read, but Now It’s Social), and it got me thinking about the future of reading, and the e-reader battle that’s currently going on, particularly between the iPad and Amazon’s Kindle.  And then I upgraded my Kindle software to v2.5 this morning, and it made it clear to me why I think the Kindle is a far superior reader to the iPad.

No one will deny that the iPad’s iBooks app has a nicer user experience than the Kindle.  It’s colorful and pretty, it has a nice bookshelf, you can turn the pages with your fingers, and, uh…  Well, that’s where it stops.  The two major issues with iBooks are:

• Since it’s a back lit display, it starts hurting your eyes when you read for too long.
• The battery life is, you know, not ideal…

Now consider the Kindle.  Though not as pretty to look at, you can tell that Amazon decided to focus on the reading experience.  You don’t have to plug it in all the time, and you can read it for hours without hurting your eyes.  But it is v2.5’s forays into social reading that really starts to set the device apart.  There are two features in particular that I think are brilliant:

• First, Amazon allows you to opt in to viewing popular highlights. This allows you to see when passages of a book you’re reading were highlighted by others who have read the same book.  It’s like a virtual book club, but instead of trying to get 6 people to agree on a book to read, you can connect with 100’s of readers who are already reading the same book.  This kind of connection really is where the Internet is at its most useful.
• Amazon also allows you to link your Twitter and Facebook accounts to your Kindle.  This means that you can highlight a passage that you’re reading, and share it with your followers, like I did this morning:

That is powerful.  It not only allows you to share what you’re reading and thinking about in real time, but it’s also great business for Amazon, since it provides a way for your followers to purchase the book right away.  Of course, even the Kindle packaging tells you that this is an experience built around passionate readers:

The differences between the iPad and the Kindle have larger implication as well, particularly in the field of Product Management.  Look, the iPad is gorgeous, it really is.  But it is an experience designed to contain so many different uses, that it is not possible to focus on doing one particular thing (like reading a book) extremely well.  The Kindle is singularly focused on readers, and that is why it beats the iPad hands down as an e-reader.

Dropbox did exactly the same thing to beat out their competitors — they focused on making file sharing as easy and convenient as possible.  They didn’t have all the features, but they made sure the features they do have has a superior user experience.  On that note, if you haven’t watched this 23-minute talk by Dropbox’s CEO where he discusses their business model, you really should.  It is inspiring and well worth it.