Insights – Full Posts

Research Studies

Viewing posts from the Research Studies category

10 Deadly Sins of Corporate Innovation

According to one of the most highly regarded innovation experts, Clayton Christensen, about 60% of corporate innovations never see the light of day and another 40% of those that are launched into a market never see a positive return on investment (The Innovator’s Solution, page 73). That means that only one in four innovations released by established companies are successful. After having worked on over fifty innovation projects for various companies and organizations, I started to see a pattern of constraints impeding successful innovation no matter the size of the company, the industry, corporate organization, or talent pool. Time and time again projects lagged, products got diluted, and useless solutions were built despite the best efforts of team members. A combination of outdated methodology, risk-averse culture, and office politics create a hostile environment for good solutions to take root in a market. This article lays out the ten most common and deleterious factors that I’ve seen suffocate successful innovation in established companies and organizations.

1. More than one person creating the vision and making decisions

When most people think about the most innovative companies in recent history, they tend to equate those firms with their leaders. Apple had Steve Jobs, Microsoft had Bill Gates, Tesla has Elon Musk, and Facebook has Mark Zuckerberg. We do not often think of groups of people when we talk about esteemed businesses or breakthrough products. Instead, we equate those companies and products with visionaries. Apple had Steve Jobs that brought to the world the iPhone among other disruptive innovations. Even though there were clearly huge teams behind the most famous innovations and many people contributed to their design and implementation, they were often driven by one visionary leader rather than a committee of corporate elites.

At the same time, many of the most challenging innovation projects that I’ve seen involve multiple product owners. This results in a disastrous dynamic for a number of reasons. The first common issue is that multiple product owners often do not agree on a single vision or on product decisions, and the more product owners there are, the less likely they are to see eye-to-eye. Every disagreement leads to substantial amounts of wasted time and halts the entire implementation team, which is hugely disruptive to productivity and moral.

Even worse than the wasted time is the outcome, which is the second impediment. Imagine if rather than Steve Jobs leading the vision for the iPhone, Apple had a committee of product managers and executives that set the product strategy and design. We’d probably end up with some kind of clunky mashup of a BlackBerry, a Motorola Razor, and the Apple Newton. (How many readers actually remember those products?) That is exactly what often happens in many corporate settings. Rather than empowering one product owner to lead the vision for an innovation, there are other executives or stakeholders that waltz in and impose their own ill-conceived changes and requirements without having immersed themselves in the need and solution design. The result is either a Frankennovation or a watered down, forgettable product that has no chance in the market.

Many of the innovation leaders that we admire founded their companies on disruptive innovations for which they provided the vision and around which they rallied their team. Indeed, it’s no coincidence that most startup businesses have three or less co-founders. Some investors and accelerators won’t even invest in startups with more than three co-founders. Moreover, even those startups that have more than one founder, one is usually entrusted with the product strategy and implementation, while the other founders focus on running the business and marketing the innovation.

Of course, having one product owner that is responsible for the product vision and decisions does not mean that nobody else has a voice. One of the central roles of the product owner is to listen to his or her stakeholders, process their feedback, and decide what to act on and what to disregard. There are exceptions to this rule such as Larry Page and Sergey Brin leading Google, but there are almost never more than two leaders, and even two rarely produce successful innovations. Any organization that does not empower its product owners to own the innovation vision and make product decisions is setting its efforts up for failure.

2. Product owner working on other projects concurrently

How many founders do you know that are working on multiple startups at the same time? Did Bill Gates create the Microsoft operating system while working part-time on another innovation? You would be hard pressed to find examples of innovation leaders successfully creating multiple breakthroughs at once. There is a simple reason for that. It’s hard enough to create one successful innovation that trying to lead two such successful efforts at once is basically impossible. Innovation just takes too much time, energy, and mental engagement to leave any extra capacity for a second or third innovation.

Now ask me how many times I’ve seen innovation leads and product managers working on two, three, even four innovations projects at once in a corporate setting. It happens all the time! If your company truly wants to create meaningful and viable innovations, you absolutely cannot allow your innovation leaders to work on multiple projects at once. If you do, you might as well write them all off. Instead, ensure that your product managers and intrapreneurs (internal entrepreneurs) only need to focus on one breakthrough at one time to allow them to truly live and breathe the problem, solution, implementation, and go-to-market efforts.

3. Product strategy and design are created by committee

Early on in my career, I was leading the strategy and design for an innovation project for a large government organization. Our team kicked off the first day of the project by gathering all the official project stakeholders in an auditorium; there were well over thirty people in the audience. Unfortunately, the expectation had been set that all the stakeholders would have input on each deliverable as the project went on.

This turned out to be a Titanic disaster as each review cycle took weeks and the design process seemed to never end. Our team would finish a round of product design, and then we’d spend the next week or two just getting stakeholders in the room for a design review. We would gather everyone’s feedback and incorporate it in the design. Then we’d have to spend another week or two getting everyone in the room again to review the revised design. In the process, those stakeholders that could not make the first review would send their feedback separately, so we’d have to reschedule the review meeting to incorporate the last-minute feedback. This pattern went on for months. Not only that, once we started building the solution, some stakeholders insisted that we stop because they felt that their feedback was not fully addressed.

It’s simply a matter of probability that the more stakeholders you have, the smaller the chance that you will be able to get everyone in a room or get everyone’s feedback in a timely manner. At the same time, it becomes more likely that stakeholders will disagree or will try to torpedo your efforts if they are not happy. Yet are internal stakeholders the true customers of the innovation that you are creating? Unless you are making an internal tool, the answer is probably ‘no.’

The primary stakeholders to whom you should be listening are customers. It is critical to set the expectation internally that unless internal stakeholders are the beneficiaries of the innovation, they are not guaranteed a say in the product strategy, design, or implementation. Once again, they should be welcomed to provide their feedback and insights, but the timing and direction of the project should not revolve around internal stakeholders if your organization does not wish to innovate at a glacial speed. The challenge is that this is often a cultural shift for established companies and this shift in thinking often needs to come from upper management.

It’s also important to note that although the above example was clearly from a waterfall based project management approach, the same inefficiencies and risks exist for agile product development efforts. In fact, they are often worse because instead of stopping just the business or design team in their tracks, stakeholders would be stopping the entire implementation team including project managers, business analysts, designers, engineers, marketers, etc.

4. Product owner never experiencing the problem firsthand

One of the key questions that venture capitalists and angel investors ask of entrepreneurs is what personal experience do the founders have with the problem that their solution is seeking to solve. This is because the founders bring a mission to the company and a vision for a solution, so they need to have completely internalized all the details of the problem. The best way to truly understand something is to experience it yourself, if possible. Although observations and interviews are great, they cannot substitute the thoroughness of understanding that personal experience affords you. It’s no coincidence that some of the most innovative products that we know today such as AirBnb and Mint started with the founders intending to solve their own challenges.

Many innovation leaders at established organizations that never take the time to experience the problem themselves. Indeed, I was guilty of skipping this step many times early in my career until I saw that lacking the insight and intuition from first-hand experience really stymied my own problem solving capabilities and intuition. I often found myself architecting solutions based on assumptions that eventually turned out to be wrong, and those product designs tumbled like a house of cards. When product owners have personal knowledge of the problem and solution space, they can build their innovation on facts rather than assumptions leading to a much higher likelihood of success.

Of course, it’s very rare that the market opportunity that the company wants to pursue exactly matched the innovation leader’s personal challenges. Instead, it’s much more likely that the product owner has to simulate what it’s like to experience and solve a certain problem. For example, long before I bought my first home, I was working on an innovation project for a large financial institution and was responsible for leading an innovation project to help bank customers find out about and apply for a mortgage. Even though I didn’t actually need a mortgage, I went through the application experience starting from square one: needing to learn about different kinds of mortgages. As MIT innovation expert and author Luis Perez-Breva states that sometimes innovation leaders need to prototype the problem, so they can experience it firsthand.

5. Product owner not leaving the building to talk to and observe people

Clayton Christensen recounts the story of Sony in The Innovator’s Solution. Christensen asks why Sony was so incredibly innovative in its early years, spawning a number of market-defining breakthroughs such as the Walkman, while it struggled to create disruptive innovations later in the company’s history. He explains that the main difference seems to have been a change in culture and approach to innovation. In the early days of Sony, the founder, Akio Morita, focused on observing and questioning people to understand what they were really trying to get done in their everyday lives. Steve Blank, another top innovation expert, coined this approach as “getting out of the building.” This approach helped Morita and his team find day-to-day challenges that people faced that could be solved for them with innovative engineering.

As Christensen points out, this period of innovation ended around 1981 after which point Sony did not create another disruptive innovation for another eighteen years. The main change during this period was a shift to hiring product leaders with MBA training to lead innovation efforts. Christensen writes:

In the early 1980s Morita began to withdraw from active management of the company…. To take his place, Sony began to employ marketers with MBA’s to help identify new-growth opportunities. The MBA’s brought with them sophisticated, quantitative, attribute-based techniques for segmenting markets and assessing market potential. Although these methods uncovered some underserved opportunities on trajectories of sustaining improvement in established markets, they were weak at synthesizing insights from intuitive observations. (80)

Indeed, in my own experiences I have witnessed a great number of product owners conceive solutions without ever personally observing or talking with customers. Quite to the contrary, those innovation leaders build complete product strategies based on spreadsheets, PowerPoint presentations, and summarized second-hand research. Once again, the typical way that leaders in corporations formulate their mission and product vision is based on generalities and assumptions rather than on detailed first-hand knowledge. It’s perhaps no wonder that a great majority of innovation efforts fail given this kind of a genesis.

Imagine if great innovators such as Mark Zuckerberg, Steve Jobs, and Akio Morita conceived their breakthrough products completely from within a boardroom. How likely do you think it would have been that a Facebook, iPhone, or Walkman would have ever been implemented as we know them? Certainly Facebook is not the only social network of the era, nor was the iPhone the only mobile phone that customers could buy. It was the details of their implementation that made Facebook and the iPhone stand out from competition and eventually dominate their respective product spaces. Can you imagine any survey or market segmentation providing the insights necessary to conceive of an iPhone or Facebook? Innovation leaders that do not get out of the building and speak to the people they are trying to serve are only setting themselves up for failure.

6. Never validating that the need actually exists and is big enough

According to one CB Insights study, about 42% of startups attributed lack of market need as a key reason the venture failed. Although I haven’t seen a similar study for corporate innovation efforts, I’m willing to bet that even fewer solutions conceived and implemented by established companies find a market need. It is exceedingly rare that product owners in established companies validate the market need in the field by speaking to and observing people, and projects often get green-lighted without convincing indications that a particular problem actually exists and that it is acute enough to address with a new product or service.

Moreover, those same innovation leaders often do not spend enough time with potential customers to understand the underlying details of the problem or why other existing solutions fail to address those details. Instead, they often rely on general market research that asks sweeping questions such as “Are you currently satisfied with your current mobile phone?” but does not provide the detailed information needed to truly understand an opportunity space and how a new innovation can improve on existing solutions. Of course, it’s not possible to answer those questions with absolute certainty, but all innovation leaders should seek to validate the need through conversation and observations and not just high-level surveys or other generic marketing research tools before leaping into a multi-million dollar innovation project.

7. Starting to build before validating solution

Does your company need to spend millions of dollars and years to validate whether your solution might be viable? Certainly not. In fact, it is often possible to get insights about a proposed solution from real people without building anything. Often times, showing people a product design or simulating a service is enough to get meaningful, actionable feedback. There is certainly a time and a place for building prototypes and minimum viable products to test solutions in truer contexts, but it’s often worth it to consider ways of testing a solution in ways that would require little or no engineering. In many cases, it’s enough to show people product designs or to manually simulate automated tasks.

For example, let’s say that your company is a financial institution that identified a need to help customers choose financial products, and the solution your team came up with was to create a chatbot with artificial intelligence (AI). Rather than actually building an AI-powered chatbot, you might simulate it by allowing customers to type in questions and return answers manually rather than using AI. There is no need to build an expensive AI engine to validate whether or not an AI-powered chatbot would be a good solution to this problem. Perhaps you’d find that a chatbot is just not an appealing way for customers to make such important financial decisions. It’d be good to know that before embarking on a costly engineering effort.

Often times, innovation teams will launch right into building under the guise of calling their work an “minimum viable product” or MVP. However, even though this term is in vogue, just calling something an MVP does not mean it’s actually minimal, and a multi-year, multi-million dollar project is almost certainly not a “minimum viable product” unless your business is a pharmaceutical company. A minimum viable product is meant to be a market-ready implementation that captures just those essential features to satisfy early adopter customers. An MVP is not meant to test the viability of a solution; prototypes are meant to do that. Creating an MVP should follow validation of the solution rather than being an instrument for the validation itself.

An even greater misstep than building solutions before they are validated is building solutions without really defining the problem or understanding the details of the problem. It is very common for companies to approve projects based on ideas rather than real market opportunities. They almost always start out with “our customers will love this product” or “our customers need this product.” Once again, successful solutions are built on the details of real-life challenges and not on assumptions.

8. Focusing on details that don’t really matter to customers

During one innovation project where I was leading the design and engineering teams, the product owners debated what shade of blue to use for over two months wasting hours of meeting time and stalling implementation. On another project, a product owner went through at least a dozen designs of one tiny icon that was found on a page buried deeply on an online tool — an effort that lasted in excess of three months and required many days of revisions and review. In both cases, our innovation teams were working on “minimum viable products.” I wish that I could say that these kinds of practices are uncommon on innovation projects in established companies, but unfortunately I have seen this pattern repeated constantly.

Customers will not choose a product simply because it is turquoise blue or sky blue or because some icon that they will rarely see satisfies their sense of aesthetic. Instead, people have limited time, attention, and cognitive bandwidth in a world where they have to process 34GB of information, make 35,000 decisions, and evaluate probably dozens of product options every day.

Many prominent entrepreneurs focus on just two or three key features that will distinguish their product from the competition. For example, Paul Buchheit, who led the invention of GMail at Google, chronicled how his team focused on just three key features when creating the first version of the breakthrough web-based email client:

  • Outstanding search for email (something Google was already great at)
  • Threaded email conversations
  • Practically unlimited storage (initially 1GB, which as more than nearly anyone needed in 2004)

Stewart Butterfield, the founder of Slack, followed a similar ethos in creating the wildly popular business messaging app. The Slack team likewise focused on three key features:

  • Outstanding search for conversations
  • Synchronization across devices
  • Seamless file sharing

Buchheit and Butterfield didn’t build products with just three features, but they focused their team’s efforts to perfect those features that would make their solutions stand out from the competition and made everything else good enough. Later on, as GMail and Slack gained plenty of traction, their respective teams could focus on the other details and fine-tuning their products as they went on to dominate their markets.

Unfortunately, the opposite is often true with regard to innovation projects at established companies. Rather than focusing on two or three key features meant to squarely meet a customer need, corporate product teams tend to spend too much time on second-order details that don’t really matter to most people. Even worse than that, those teams spend time and resources on making everything perfect before validating the core problem is substantial and their solution is better than alternatives. This mentality is what gives rise to multiyear, multimillion dollar “minimum viable products” and leads to unimaginable inefficiency and loss.

9. Not continuing significant product improvements after launch

A common practice among startups is getting a minimum viable product to market quickly and then iteratively improving it once people use it in a real-life context and can provide feedback based on reality rather than conjecture. This approach let’s startups adapt quickly as they receive fresh input from customers. At the same time, they can build new features incrementally rather than spending tons of resource on creating feature sets that might turn out to be poorly implemented or just not useful to customers.

Unfortunately, corporations tend to launch innovation projects and directly go into maintenance mode rather than treat the launch as the beginning of empirical product development conducted in a real-life context rather than in a lab or conference room. This misstep is often driven by spending too many resources going to market with the initial implementation and running out of runway to iteratively perfect the product after launch. It is critical, therefore, to launch early and build into all innovation projects a period of iterative product development once the minimum viable product has been launched in the real world.

10. Never finding product-market-fit

No matter how great an innovation is, it is worthless if the business does not effectively find and reach a group of people that will use it or buy it. Any impactful innovation needs to provide a superior solution to an acute problem. Additionally, the company needs to find and effectively reach the corresponding market. Product-market-fit is when the right solution meets the right market. However, companies often just launch innovations and fail to find traction for them in the market. Worse, some companies never even try to validate whether or not the company has found the right market for the innovation and if it meets people’s needs well enough that a significant number of them will pay for it or will use it regularly.

Many established companies launch innovations but never ensure that they can effectively reach the right customers. Instead, those companies launch solutions without organic product-market-fit — traction with customers that is not bolstered primarily by the company’s brand or marketing spend. Why engage in costly efforts to create innovations if they are left to drift along and sap the company’s brand equity or marketing resources? Creating a solution is just one part of product-market-fit. Without spending resources to ensure that the solution reaches traction in the market by measuring adoption and iteratively improving the solution, companies miss the other half of what is needed to create a viable innovation that adds to — not detracts from — the company’s bottom.

Avoiding the 10 deadly sins of corporate innovation

There are a number of pitfalls along the long journey of innovation in established companies, but it’s possible to avoid them and increase the probability of creating successful solutions. To a large extent, the above challenges can be mitigated with good planning and setting the right expectations. For example, it’s important to plan for project phases aimed at understanding the problem and validating solutions early. At the same time, by setting expectations that the product owner will be solely responsible for the vision and major strategic decisions, leaders can ensure that their innovation efforts won’t be stymied by design-by-committee and endless review and feedback cycles. We will cover specific tactics to address the innovation challenges mentioned in this article next week, so be sure to check back then.

Avoiding Agile Disaster

Agile development can be a wonderful thing. Unlike a waterfall approach that can be mired with checkpoints, bottlenecks, and other friction, Agile can free organizations to move quickly. However, with that freedom come deleterious consequences. Chief among them is the loss of  product identity, which leads to an unrecognizable agglomeration of disjointed features—A blob of garbled parts.

A Blob of Garbled Parts

One of the first questions I ask usability study participants is, “What do you think this thing does?” All too often, the answer is simply “I have no idea.” In other cases participants grasp at random guesses. In the case of Agile development, the cause usually lies with a loss of strategic vision.

Agile works in small, fast sprints that focus on features. In this high-paced product development framework, a myopic mindset often takes hold causing the team to lose sight of the big picture. Rather than asking how each new feature will support the overall product strategy and how each feature will work together to form a whole, teams are just focused on the feature-du-jour. The result is a mishmash of disconnected features–an amorphous blob, not a product. When you ask people what they think it is, you are really giving them a Rorschach test.

This is a problem for an obvious reason. No one wants an undecipherable blob of garbled stuff.

How to Spot the Blob

Luckily, it’s pretty easy to identify if your product is an amalgamation of disjointed features.

  • Open yourself to critically examining where you are.
  • Find some people that have never seen or heard of your product, show it to them briefly and ask them what they think it is and what it does.
  • Allow your subjects to interacted with your product for a few minutes and ask them again.
  • If more than half the people you interviewed cannot tell what your product is or does, you have a blob of disconnected features.

How to Fix Your Blob

This is the difficult part. Often, you have devoted so much time, effort and money into getting to where you are, that it is next to impossible to let go and clean up. Here is what to do:

  • Understand that if you do not consolidate your mess of features into a coherent product, it will only get worse and you will lose more time and money.
  • Without looking at what you have, state your product vision. (E.g. a community for people to share documents.)
  • Itemize all of your product’s features and ask whether they support your product vision. (Do you really need a video editing feature in your document sharing website?)
  • Cut all those features that do not support your product vision.
  • Look at the remaining features and ask how they fit together to form a unified product. (E.g. How does sharing by email relate to new user registration?)
  • If you identify features that do not work well with others, figure out a way to better integrate them.
  • Test the final product to make sure that you actually do have a product that people can understand and want.

How to Avoid the Blob

An ounce of prevention is worth a ton of cure in this case. It is substantially easier and cheaper to avoid losing the products identity than trying to recover it. Below are the steps to make sure that you build a product with a strong identity.

  • State your product vision if you haven’t already done so. (See above.)
  • With every new feature in the pipeline ask how it will (a.) support the product vision, and (b.) fit within the existing whole.
  • Develop a strategy for each feature to support the overall product strategy and to work seamlessly with the other features.
  • Ensure that the design and implementation of each features meets the above two criteria.

The Infinite Pivot and the Death Spiral

We all know them: start-ups that are caught in a cycle of infinite pivots. (I’m sure you’ve already seen the lampoon Vooza.) Sometimes it’s very obvious that a company is pivoting endlessly; other times it is much more subtle. Agile development is very prone to this chronic condition since it is so easy to change tack. What are the tailtell signs that your organization is stuck in an infinite pivot?

  • Your customers don’t know what your product is or what it does.
  • Every new customer support email prompts a new feature or revision.
  • You are often undoing previous work.

If any of the above sounds familiar, your organization might be stuck in an infinite pivot. Of course, pivoting is a vital step in any new company, but doing it too often will erode your product’s identity and leave you with a blob of disconnected parts as well as a fleeting customer base. When things get bad enough, your product can go into a death spiral.

The Infinite Pivot is really just a special case of the Blob of Garbled Parts, although it arises for slightly different reasons. The main culprit in this case is also a lack of product vision but also an over-sensitivity to customer and stakeholder opinion. What I mean by the latter is that the product heads make new product decisions every time they get a new piece of feedback from a customer or stakeholder. Take, for example, a shopping web site. A few customers write in wanting bigger product images, so the product team updates the web site with bigger images in one sprint. Then an investor insists on making the images smaller to fit more products on the screen, so the images are shrunk in the subsequent sprint. Sound familiar?

A strong product vision would curtail this scenario. Conflicting feature requests would be evaluated against the overall product vision. Do bigger or smaller product images support the product strategy? This is dictated by what kind of online store you are building, which is driven by business strategy.

How to Avoid the Infinite Pivot

As in the case of the Blob of Garbled Parts, the emphasis is on clearly stating a product vision and building a product around it. However, it is also important to develop an effective system for incorporating feedback.

  • Customer insights and stakeholder opinions should be viewed as a whole not piece by piece. For example, how many customers complain about the product images? Do more people want smaller images or bigger ones?
  • Each feature request should be scrutinized to see if it fits with the overall product vision as well as with existing parts.
  • If the feature request makes the first cut, one must guage its feasibility and its priority vis-a-vis other features in the pipeline.

Following these steps should help to ensure that you do not change tack too frequently and maintain a strong product identity.

Stay True to Your Product Vision

In my experience, the most common danger associated with developing products in an Agile framework is focusing on building individual features rather than a product. By clearly defining a product vision and ensuring that all development supports that vision, you can focus on building something that your customers will understand and, more importantly, want.

People Prefer Choice over Better User Experience

Recent research suggests that if consumers perceive that their freedom of choice is limited, they will often switch to a new product from one with which they are already familiar,  (“Why Dominant Companies Are Vulnerable“,  MIT Sloan Management Review,Winter 2012). The researchers, Kyle B. Murray and Gerald Häubl, explain that this phenomenon might be one important reason why market leaders such as Microsoft lose dominant market share over time. For example, consumers might opt to switch to the Firefox web browser and endure the cost of learning a new software simply to exercise their freedom of choice. Not only that, Murray and Häubl found that consumers might make the switch to the competitor even though the competing product is not as good.

The experiment consisted of websites with different interfaces that allowed users to search for new stories. Some participants were allowed to choose the website to use while others were not. Specifically Murray and Häubl found:

51% of consumers who had no choice in selecting the interface they learned to use switched to a competing website as soon as it was available. By contrast, among consumers who were free to choose the website they would learn to use, only 23% switched to the competitor, despite the fact that other users rated the competitor’s website superior on several dimensions (including ease of use, fun, efficiency and effectiveness)… [We] found that the market leader’s advantage in being able to install a set of nontransferable user skills in its customer base is offset by psychological reactance, a force that motivates people to act against perceived constraints on their freedom of choice.

Murray and Häubl go on to explain:

As people learn to use a particular electronic interface associated with information search or online shopping, for example, they often become locked in and develop extremely high levels of loyalty even when otherwise equivalent competitors are available; the cost of switching outweighs the benefit of using another product. However, our research indicates that the depth of loyalty weakens when consumers feel that their freedom to choose is restricted. Specifically, as people feel that their choice is constrained and that one interface dominates the market, they react against the constraint by turning away from the market leader’s offering, thereby subjecting themselves to the associated costs of switching.

What does this mean for product strategy? Strong-arming customers to stick with a particular product might actually alienate them rather than foster their loyalty.

Market Research and the Primitive Urges of the Consumer

“The trouble with market research is that people don’t think how they feel, they don’t say what they think and they don’t do what they say.”

The BBC reports on an upcoming breakthrough for market research, currently being developed. Dr Roberto Valenti of the University of Amsterdam and Dr Theo Gevers.

The two have established a company, ThirdSight, to take advantage of computerized emotion recognition (decoding emotions from facial expressions). ThirdSight has successfully run its software on a smartphone, but the team acknowledges that results are not yet perfect, requiring a researcher to oversee the software, because it cannot decode context or hidden meanings. For instance, it considers both a happy smile and a bewildered smile as ‘positive’.

This technology poses some promising power in the future of market research.

Read full BBC article »

The Real Life Social Network

I loved this presentation by Paul Adams of the Google UX team. He explores designing for real social networks by examining relationships, influence, identity and privacy.

The entire presentation is extremely well done, and the discussion around relationships and our online versus offline social network truly illuminates important factors in social design.

Read More

Ratings by Communities Are Skewed—Now What?

Many online and mobile applications rely on ratings and reviews from their communities to provide wisdom for their remaining users. Services such as Yelp, Amazon, Digg, and even the Apple App Store use input from their users to evaluate some intrinsic value of a set of items—be they books or iPhone applications.  However, new research recently published in the MIT Technology Review suggests that the wisdom of crowds can be inaccurate and misleading. Does this cast doubt on the utility of community-driven rating systems?

Vassilis Kostakos, an adjunct assistant professor at Carnegie Mellon University and his team confirmed that the rating systems commonly used can “easily be swayed by a small group of highly active users.” The Technology Review article goes on to write that “rating systems can tap into the ‘wisdom of the crowd’ to offer useful insights, but they can also paint a distorted picture of a product if a small number of users do most of the voting.”

Although Professor Kostakos’ research validates a suspicion that many have had, it does not necessarily mean that community-based review systems are useless. The article states:

Jahna Otterbacher, an assistant professor at Illinois Institute of Technology who studies online rating systems, says that previous research has hinted that rating systems can be skewed by factors such as the age of a review. But she notes that some sites, including Amazon, already incorporate mechanisms designed to control the quality of ratings–for example, allowing users to vote on the helpfulness of other users’ reviews.

Kostakos proposes further ways to make recommendations more reliable. He suggests making it easier to vote, in order to encourage more users to join in.

What this means for the design of interactive products with such rating features is that steps should be taken to ensure a more representative outcome of user-driven reviews. The following factors can be considered to that end:

  • Count only one vote per user.
  • Provide a mechanism for users to vote on the usefulness of written reviews, and factor that into the total score.
  • Make it easier for all users to vote to capture a broader cohort.
  • Factor in the network patterns of user voting. For example, if a group of users consistently votes together on items, perhaps compensate in the algorithm for that behavior as it tends to skew results.

Eye-Tracking Studies at Google

Two user experience researchers share on the Google Blog how their team conducted eye-tracking studies on the interface of Universal Search to gain insight into optimal information design. They write in their post:

Our User Experience Research team has found that people evaluate the search results page so quickly that they make most of their decisions unconsciously…. Of course, eye-tracking does not really tell us what they are thinking, but it gives us a good idea of which parts of the page they are thinking about.

Read More

Modern Mobile Phones Frustrate Most Users

The BBC reports on a study conducted by Mformation, which reveals that of 4,000 people interviewed in the UK and US, 61% claim that “setting up a new handset is as challenging as moving bank accounts.”

The report reveals other details of the complexity users face, such as using various applications, browsing the web, reading email, and sending picture messages. Results include:

“Of those questioned, 95% said they would be more likely to use new features if the initial set-up were easier.”

“Some 61% of those questioned said they stopped using an application if they could not get it working straight away.”

“Having icons for all a phone’s available services at hand was better than burying them in a sub-menu …”

via: Experientia

On Usability Problems with Voting Machines

Today is the big day, and no matter for whom or what you are voting on November 4th, you not only want your vote counted, but you also want it counted correctly. In the spirit of fair elections with a twist of usability geekiness, we at Montparnas compiled a few resources where you can learn more about usability of voting machines.

Usability in Civic Life: Voting and Usability Project

The Usability Professionals’ Association (UPA) has been running a great project that seeks to evangelize good usability in voting machines. It’s one thing when it’s difficult for a user to add an item to a shopping cart, but it’s a whole different ballgame when votes that determine a presidential election are miscounted or not counted at all. Usability in voting machines is perhaps the most important application of the usability engineering field. The UPA writes on their site

Read More