An artist approaches a blank canvas and must decide what to paint. What is the purpose of the painting? What feelings should be evoked when viewed? If the artist wants to paint realistically, it helps to have personal experience with the subject matter of the painting. This is needed to accurately portray shadow and light, or to convey the soft texture of the subject’s surface. The artist must know the subject, and deeply comprehend it, in order to properly represent it on the canvas.
The same depth of comprehension applies to design. And it is in design that this comprehension produces more than mere aesthetics. It must produce functionality. It must promote efficiency of interaction and conveys feeling.
Hands-on time with the subject matter is the best way to gain comprehension and the ability to share this comprehension with others. It is about being engaged and involved. Sometimes the designer does not have the opportunity for hands-on experience. We cannot overlook the opportunity to learn from those who have it, and after all, these are the people who will actually be using the product that is being designed.
When my Human Centered Design team is presented with a problem, we use a framework called Goal-Directed Design (GDD). Goal-Directed Design was created by Alan Cooper and is a method that helps software teams to identify the goals and behaviors of users, and the goals of a business, and then directly translate these into models that can be user-tested and refined to converge into an implementable design. This process allows us to gain an understanding of the problem. We capture presumptions held by the business and form multiple ‘hypotheses’ in the form of low-fidelity testable mockups. We test the hypotheses with users, and iterate the designs based on the test results. The result of several rounds of design iterations are a usable solution, and a strong product vision to serve as a North Star across the organization.
This article discusses how my Human-Centered Design team uses the Goal-Directed Design framework to find solutions to design problems. The milestones for Goal-Directed Design are: Involve Users, Define Goals, Model Work, Product Vision, Skeleton Requirements, and Implementation Support.
The Goal-Directed Design framework submerges the team in an environment that promotes Design Thinking. My team began with an understanding of the problem. We become intimately familiar with the players involved, and by going on-site and observing the users’ interactions in their natural environment. Once we observe users performing their tasks within their native environment, utilizing native processes and tools, then we could start thinking about a solution.
Where to Start
Planning is the first step. This includes the project intake, identifying the stakeholders and assessing the team’s capacity. The outcome of this process is the Project Plan and a Design Brief. The Design Brief presents the problem statement and the overall goals of the new design. It also describes what is known about the limitations with the current design, the target audience, the schedule and milestones, design scope, design criteria.
Next Start Asking Questions
To open the door to innovation, we must start out with the assumption that we know nothing about what will really make the user happy. Taking this “blank canvas” approach gives room for new ideas to form. We begin by “roughing out” low-fidelity sketches. These are shown to users to spark conversations about their needs. The designer must accept all possible outcomes: The sketches will be accepted (i.e. ‘validated’) modified to some extent, or completely rejected. Designs that are rejected by users are removed.
The process compares to the game of Scrabble, where a player may spot an opportunity to create a word. But one should not pounce on this opportunity without looking around for better opportunities with a higher point value. Similarly, a designer can quickly come up with a design solution. But is it the best solution? That is, will the solution work for different users? Have we succeeded on exhausting all possible design patterns that could be applied to the same problem? These questions must be asked so that the solution fits into the appropriate work context – not of the people who must build the design, but of the people who must use the design to complete critical tasks.
This is why multi-layered research is essential. We understand the implications of designing in collaboration with one person or a few people. If that one or those few are not the people who will end up using the product day in and day out, there is a risk that the design will be moot. Thoroughly doing research means gaining an understanding of all of the different end-users and the jobs they need to do when they use the product.
What is Usability Research?
My Human Centered Design team identifies and interacts with users in their natural work environment. We collect demographic information, conduct Contextual Inquiry interviews, and perform a variety of user tests to collect as much useful information as possible from as many people as possible within our allotted time.
After each time we meet with customers we have a briefing session with the remainder of the team to listen and discuss the account of what was learned during the customer visit. In this session we watch the videos, and share documents that our users provide to us. We have in-depth discussions around what was observed about the user’s work practices, beliefs, goals and values.. Only when we understand and identify users life goals, end goals and experience goals does sufficient context emerge to begin human-centered design.
The most essential part of the process is making sense of the data. The information from each interview is transcribed into a spreadsheet, and eventually ends up on a 3×3 note ready to be posted on an “affinity wall”. This wall is visual part of the process, a diagram, which helps us identify the similarities and characteristics underlying relationships. Identifying affinities is the cornerstone for creating personas, information architecture, context scenarios, elements and themes. All of the usability artifacts created from that point forward should trace back to data that is located in the affinity diagram.
The Mechanics of Creating an Affinity
An affinity exercise is a great way to get everyone on the team involved even from other parts of the business. Find a place with plenty of wall space where the affinity wall can be located for the remainder of the project. During the affinity meeting, each participant will take some of the 3×3 squares, and place them onto the wall. As each square is placed, the contents from each square should be read out loud and discussed. There should be conversations about where the square should be placed in relationship to the other squares on the board. The process may appear chaotic at first, with random and unrelated squares on the wall. But as more and more squares are placed, the team will begin to see similarities and patterns. As the squares are assembled in groups, resist the urge to label them. Continue to look for design ideas and breakdowns in the users’ existing processes.
As more and more squares are added, keep the groups small and feel free to move squares from one group to another if the relationship is stronger in a different location. Once the movement of the 3×3 squares has come to a stop, then begin adding labels groups.
Keeping the affinity wall in highly visible location lets designers reference the research data with ease. It inspires the designs to follow.
What’s Next? Converge on a Design!
The design possibilities really start to open up when an affinity wall is created. It allows the team use what was learned thus far. It leads to a wealth of new artifacts to communicate the teams’ discoveries.
The next step is to use the 3×3 card groups posted on the affinity diagram and cluster them into higher-level groups. These higher level groups will become the UX Elements and Themes that are reference throughout the rest of the design.
On the affinity diagram, identify the different types of users to be referenced when writing in the context scenarios and storyboards. These are Personas that will be used to integrate user nuances into the overall design. Personas are believable but not real people. They convey the users’ goals and frustrations and how the product is going to solve their problems.
Next, write Context Scenarios based on the affinity diagram that express how the product solves the problems that the persona faces.
Finally, write Storyboards that illustrate how the new product will please the user. Put the product into context by illustrating how it fits into their lives. Really convey how this will delight the user. The mockups and storyboards are then put in front of users to guide the design team with their feedback.
Share the Product Vision
Once the artifacts have been iterated to include user feedback, its time to share the Product Vision to Stakeholders and Engineering. During this process, we review the steps that were taken up to this point. We share Storyboards, Personas, Goals and Motivators. We provide a UI Architecture, glossary, and a clickable prototype. We define the interface components to ensure term alignment and productive conversations between the teams.
Are you now seeing the big picture? After all of these steps are taken and we know what the user needs, requirements can finally be written. Updates will be made to fit the design within engineering constraints. It is important to keep the vision as intact as possible so style guides and governance processes are created and shared to support development.
The Human-Centered Design team should be available for support and consultation. Regular meetings should be scheduled to ensure there no images or other supporting artifacts are missing, which could block development. Share engineering progress early and often to get feedback. This way you can be assured that the can implementation follows the design as closely as possible.
After the Product Vision is transitioned to engineering the Human-Centered Design then conducts a retrospective to discuss the project successes and set-backs. Commitments should be made to things that should be done differently next time to improve projects in the future.
I hope this post shed light on the advantages of leveraging the Goal-Directed Design framework. By conducting the proper user research and sharing findings with stakeholders and collaborating across the Product Development team an understanding can be achieved of the users’s goals. The final result is a product that exceeds what can be designed in a silo. When data is synthesized into an affinity diagram, it gives a reference point for the value proposition of the final design moving forward. Testing often and early allows the incorporation of feedback and ensures that the final design will fulfill the needs of the user.