We can only design solutions for people when we have a deep, detailed knowledge of those people’s needs.
We can only design solutions for people when we have a deep, detailed knowledge of those people’s needs. We build upon our prior knowledge and experience to design and develop better products. Each new generation of solutions improve based on market and customer feedback.
Sometimes the best way to satisfy a customer’s need is to ignore their suggestions. “Customers have ideas about incremental improvements to their workflow, but if we develop something that is truly innovative, our ideas probably won’t make sense to existing customers.”1 Sometimes when we solve a market problem, our solution may completely eliminate existing workflows, activities, and tasks with a better process. In many cases, customers only know their way of doing things while we have a broader perspective across many customers’ processes and a deeper understanding of technology capabilities. An individual customer does not have our aggregated view of the larger market problem across multiple customers and a deep understanding of technology.
Listening to our customers’ suggestions may lead to incremental improvement instead of real innovative market solutions but ignoring them all together can produce even worse consequences! It is by going out and observing our customers using our solution that we see how they interact with our products in their environment. There are many things people never verbally communicate because they are unconsciously doing them or they do not see them as important. For example, they may have created special information “cheat sheets” they need to do their job. I have observed numerous customers’ end-users who have a spreadsheet on their network to manage information that could be incorporated into the product and completely change the way they accomplish activities. Most customers do not have the deep understanding of technology capabilities. And, from their perspective, we are, quite frankly, one of many vendors to them— just a part of their overall process—and they think of our products and solutions in this context.
A deep understanding of our customers’ needs is still required to make great solutions. But it also requires a deep understanding of technology, tools, and of the reasons for our customers’ activities.
Dr. Donald Norman has suggested a hierarchical structure of activities, tasks, actions, and operation2 to better understand our customers’ interactions with solutions. In this model, activities are comprised of tasks, which are comprised of actions, and actions are made up of operations. This “activity-centered” philosophy is focused on the activity—not the person. If a customers’ suggestion fails to fit the design model, it should be discarded. Too many companies, proud of listening to their customers, will include requested features that do not really solve the bigger market problems. Only by observing our customers activities—interactions with our products—do we really understand customer’s needs.
Successful product designers understand their customers’ activities to determine how the solution will best operate. Understanding the tasks of the activities helps understand the customers’
intentions. Focus on activities our customers perform rather than their requests. Systems that support the activities must, of necessity, support the people who perform them. Successful products are those that fit gracefully into the requirements of the underlying activity, supporting them in a manner understandable by their target customer. Understand the activity, and the solution is understandable.
markets and adapting it to our own. The solution’s vision provides the direction for the product’s design.
The product manager must have a concise vision for the product they can clearly articulate to the product designers. Put the customers and users activities in context of the market problem the solution is solving. Markets are “made up” of segments. We must be able to define our market segmentations in terms of their needs in context of the problems we are solving for them. Both demographic and psychographics help to develop segmentation profiles.3 Consider the strengths and weaknesses of the competitions’ solution compared to your solution along with how the various customers’ goals, process workflows, activities, and tasks are similar and different. Remember that innovation sometimes means looking at a solution in other markets and adopting it to our own. The solution's vision provides the direction for the product's design.
The product team must follow the vision and not be afraid to ignore findings. Yes, listen to customers, but know when the findings support the vision. Vet assumptions, validate design concepts with customers, and evaluate the solution with customers’ end-users. Review market segmentation demographic data and interview stakeholders, customers, and users, in order to gain insight into their goals. A goal is a result one is attempting to achieve. Observe the customers and users using the solution in their environment and develop diagrams of the various customers’ workflows and note where the goals and underlining activities are similar and different.
Group your customer and user by similar roles based on their goals and the type of activities they perform. A role is a set of connected behaviors. Usually people with the same role have similar job-related responsibilities, duties, and goals.
Once the various roles and goals are understood, think through the scenarios needed to realize the goals. Scenarios describe a user’s interaction with the solution. Scenarios are useful to Product Management to define business cases and useful for Product Design to define user interface design.
Determine what activities are needed to complete the goals by roles. An activity is a specific behavior or grouping of tasks. Develop a diagram that illustrates the activities. An activity diagram shows activities and actions to describe workflows.
Product designers have tools they use to define activities, tasks, actions, and operations such as activity diagrams, wireframes, and prototypes.
Activity diagrams divide the activities into tasks needed to complete the user’s objective. A task is a unit of work. The task itself may be a single step in the process or multiple steps or sub-tasks that make up the task. Activity diagrams, sometimes called process flow diagrams, divide the scenario tasks as needed to convey what the user needs to do to complete their goal.
Sean Van Tyne, AVP User Experience, LPL Financial,solves business-critical problems where people intersect with technology. Sean is: the current President of the User Experience Special Interest Group, www.uxsig.org; a member of the Board of Advisors for UXnet, www.uxnet.org; and advisor on a number of professional and corporate boards. Contact Sean at Sean@VanTyneConsulting.com