Defining and Designing Technology for People
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.
Ignore customer suggestions
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.
Understand customer 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.
Define who, why, what, and how: roles, goals, scenarios, and activities
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.
Design activities, tasks, actions, and operations
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.
Tasks analysis looks at tasks as outcomes that have actions. Actions usually result in some form of commitment. For example, selecting the “OK” button in a software interface or pressing a button on a device that results in a desired outcome. And an operation is the outcome of the user’s action. The operation is the program initiated and yields the results of the user’s intended goal.
Product Design develops prototypes to elicit customer feedback to validate the solutions activities, tasks, and actions meet their needs. Wireframes are a quick and easy way to prototype a design for feedback. Wireframes are a basic visual guide used to suggest the layout and placement of fundamental design elements in the interface design. They provide a visual reference for the structure of the screens, define the positioning of global and secondary levels of information hierarchy, and maintain design consistency. It is a way to visually represent the activities, tasks, and actions.
With wireframes, designers validate the general workflow navigation, information grouping, information hierarchy, terminology, labels, and general interactions in terms of activities and tasks that need to be complete to meet the customers’ goals. Wireframes and lo-fidelity prototypes, in general, should be void of all color, fonts, icons, graphics, etc. to keep the focus on the overall workflow, activities, tasks, and general information design.
When solving problems for the broader market, these prototypes allow you to validate where various customers’ workflow and content overlap and differ, and start thinking about the right design solution to support the differences in their workflow, activities, tasks, and content.
Once you’re confident you understand various customers’ workflow, activities, and tasks, it’s time to develop visual design—color scheme, fonts, iconography, branding, and all graphic elements. Visual designers develop the visual design elements that support the company’s brand and enhance the ease of task completion and efficiency.
Medium-fidelity prototypes are developed based on wireframes and visual design. These prototypes encompass screen flow and interaction. Interaction Design defines the behavior of how your customers and users interact with your solution. They focus on the tasks that need to be completed and the actions associated with the task and underline operation. Interaction design is focused on making products more useful, usable, and desirable.
Work with customers and users to conduct reviews of prototypes for feedback. Conduct usability evaluations to measure effectiveness, efficiency, and satisfaction. Be sure to measure task completion, time and task, and the emotional response to your solution.
Win in the marketplace
We can only design solutions for people when we have a deep, detailed knowledge of those people’s needs. Just listening to our customers’ suggestions only leads to incremental improvement instead of real innovative market solutions. It is by going out and observing customers using our products in their environment that we gain deep understanding of our customers’ needs that is required to make great solutions.
Successful products 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. With an activity centered design, focused upon the activity rather then the person, ensures we develop innovative solutions that win our marketplace.
 Van Tyne, Sean, “Easy to Use for Whom: Defining the Customer and User Experience for Enterprise Software.” Pragmatic Marketing, Volume 5, Issue 3, 2007
 Norman, Don, “Human-Centered Design Considered Harmful,” http://jnd.org/dn.mss/human-centered_design_considered_harmful.html
 Bean, Jeofrey and Van Tyne, Sean, Market Aligned User Experience Seminar, October 5, 2008, Del Mar Doubletree, San Diego, CA
Looking for the latest in product and data science? Get our articles, webinars and podcasts.