Moving from Vision to Design: User-Centered Methods for New Product Definition

Seminar by Dorothy M. Danforth for the IEEE Computer Society Leading Professional Seminar Series. – 30 minutes

It’s a common scenario: A company is planning a new product or significant redesign. There have been various discussions about how the product should have a “great user experience” and “focus on the user.” But, there are also conflicting ideas on what a great experience might entail, along with competing priorities for what the product absolutely must do to be successful in the marketplace. ​

Where to begin? How do you break through the confusion and move towards a clarified product vision? Whether a large established corporation or lean start-up, organizations struggle with progressing from early ideation into clear requirements and a tangible design phase. This webinar will explore ways to leverage user experience design methods in the very early stages of the product life cycle.

This session covers the following:

  • An overview of practical user research and design planning methods useful for early stage products and redesigns
  • Strategies for leveraging these methods to refine a product’s vision and ensure features are tied to user goals
  • Examples of how keeping a focused eye on user needs can help resolve conflicting priorities and promote product team alignment
Blog Post

User Experience Design Myths

This article attempts to dispel some common myths you may have heard about adopting user research or a user-centered design approach.

We Don’t Need UXD Because…

  • Our users are early adopters, or are our employees…
  • We are just trying to create a technical proof of concept…
  • We work iteratively in an Agile development environment…

Whatever the reason, consider this, there is no demographic that likes a poorly designed product. UXD foundations are arguably the most direct and efficient means to a well designed product. They can be adapted to any type of application or product lifecycle stage. Therefore, while your product may not need a complex UXD process or a specialized UXD team, the basics of user-centric design are always appropriate and will unilaterally result in a better product when appropriately applied.

UXD is Too Expensive

UXD methods can easily be modified to fit your budget. Each research method in this guide can be adapted to be implemented inexpensively and with very meager resources. In fact, an appropriately defined research plan should reduce costs by getting you much closer to what your end users want with far fewer problems post release. Maintenance costs related to unmet or unforeseen user needs can be as high as 80% of the overall development lifecycle costs. (Pressman, 1992) There is good reason why UXD is a growing field within software design; it shows a strong ROI.[1]

UXD Slows Down the Development Cycle

UXD can reduce and simplify the product development process. A common misconception about user-centric design is that it adds to, and slows down the development cycle. And yes, UXD can be incorporated in such a way that it needlessly adds time to the process. However, it does not have to. In fact, as early as 1991, a study found that usability engineering demonstrated reductions in the product development cycle by 33 to 50%. (Bosert, 1991) A well integrated, process-appropriate UXD effort will not only produce a more successful product, but will reduce development time and costs.

UXD is mostly useful for Consumer Products

Some form of UXD is useful for any system a user can interact with. Can users easily find what they need? Are common tasks simplified and not an unnecessary drudgery? Are the labels clear and do they use commonly accepted terms? All these UX related questions are as relevant to a consumer-focused e-commerce site as they would be to a billing operations system. UX Methods can be adapted and applied to information/marketing interfaces as well as transactional applications. The main difference is the goal, i.e. successful UXD on a consumer product usually drives more sales; while success in an operations system usually takes the form of higher adoption rates and increased productivity.

UXD Only Affects the Presentation Layer

UXD is more than skin deep. Don’t get me wrong, with a background in the arts; I see the value in making things look good, and most people respond to a pleasing visual design. But thinking of UXD as a presentation layer process will substantively limit its ability to improve your product. A good example of how UXD has an impact on functionality is in the case of faceted categorization for parametric searches[1]. User Research can not only help you determine how these fields should be laid-out, but how to categorize the data, what to name categories, and what kind of search groupings users want.

User Research will help us Define the Right User Experience

Well, you can try. But it is important to understand that there is no single “correct” user experience for a product. The process of interpreting the results of User Research and deciding how the resultant insights should be translated into final designs is probably best considered an art informed by science. It’s quite possible (and common) to have two totally different, yet viable, directions that both address the same user goals and requirements. (In these cases, additional criteria can be used to determine what direction to take i.e. budget, time, brand alignment, other features etc.) Despite its inherent lack of absolutes, User Research can, however, give you the best educated-guess possible regarding your users behavior, addressing upwards of 80% of issues before taking a product to market.

User Research is Market Research

User research is not market research. While there is a strong brand/marketing component to user experience design, the research methods are distinct with different methodologies, considerations and results. Unlike market research, UX research is less concerned with what features are available, or what the marketing messages are, as it is with how successful a specific design is in articulating its features and how usable and accessible the product is for the end user.

Market research is business-centric; it uses the analysis of data in an attempt to move people to action. While user research is (you guessed it) user-centric, its goal is to analyze user behaviors and preference to better design for them. Often, these two are means to the same end. Sometimes however, there is a conflict. An e-commerce website could have a promotional pop up screen that most users find annoying, despite the fact that it generates a good deal of revenue. The UXD practitioner should be free to advocate for the users’ goals, and the marketer for the business’ goals. Any resulting compromises should be considered in the broader context of the company’s brand.

User Research is only useful During Requirements Gathering

While very useful during requirements gathering, there are real benefits of incorporating this research throughout the software development lifecycle. Validation is a big part of user research. What in the design phase sounded like a good idea and tested well, might not work as well in its final implementation. There are a number of inevitable changes and revisions that occur during development. It’s important to retest and validate your release after all the pieces of the puzzle have been put together. This can be achieved with participant-based user testing or by providing structured feedback mechanisms in a beta or limited pilot program.

Here are some sample User Research methods for each phase of the software development lifecycle:

  • High-Level Requirements

o    Ethnographic Studies

o    Concept Prototypes & Testing

o    Surveys with a Broad Focus

o    Competitive Reviews

  • Detailed Requirements

o    Validation Tests for Screen and Workflows

o    Tactical Surveys

o    Graphic Design Reviews

  • Development & QA Testing

o    Validate Changes and Workarounds

  • Release/Deployment

o    Feedback Forms

o    User-centric Beta or Pilot Testing

  • Maintenance

o    A/B Split Testing