In October 2019, a group of human-centered designers, agilists, data scientists, and other technology enablement practitioners joined to share their thoughts about a topic of common interest: How should the principles and practices of human-centered design, Agile development, and the overarching process of HCDAgile be applied to products that have no obvious user interface?
The group’s objective was to develop guidance based upon shared knowledge across disciplines and industries for leveraging HCDAgile in data projects. In this paper we share our initial observations from the meeting.
(Note: For the purposes of this discussion, human-centered design or HCD will be used as an umbrella term that encompasses all aspects of UX/UI, CX, UCD, usability, and related disciplines.)
What Are “Data Projects”?
First, let’s define what we mean by data projects. Data projects, as we define them in this context, are of two types. The first involve “big data” engineering projects: products that focus on moving, consolidating, and refining large quantities of data from one source to another for—ultimate, but far downstream—use by humans. The second type of data projects are those related to data analytics.
Examples of data projects include the following:
- The design and development of a pipeline that moves data from farming machinery to the cloud so it can be transformed into maps, reports, and geospatial data for data-derived insights.
- The creation of a “data lake” that collects disparate bits of a credit card transaction and unifies them to allow a bank customer service representative to easily identify fraudulent activity.
- The design and development of a data warehouse for academic medical research that aggregates data from multiple sources and follows a standard that will allow collaboration among peer institutions.
- The design and development of a system which gathers customer data from dozens of business units and more than 8,000 data sources that can be associated with an individual customer and downloaded as a single file.
- Collecting hourly utility meter data for millions of customers, and making the data available in a format to make it usable for analysis and visualization with minimal lag time.
At first glance, these projects seem to have no need for human-centered design. After all, most people think of HCD professionals’ tasks as mocking up screens, testing the usability of interfaces, observing end-users, and otherwise crafting and measuring user/customer experiences. By contrast, data projects seem to be devoid of end users. Data projects address the “guts” of systems—the “plumbing”—far removed from what a user or customer sees, hears, and touches. So why include HCD on such projects?
Why HCD for Data Projects?
First, before addressing why there is a need to apply HCD to data projects, let’s step back for a moment and define HCD. While many definitions of HCD are readily available on the web, from industry publications and academic literature, for the purpose of this paper we’ll use two representative sources. Don Norman’s classic work The Psychology of Everyday Things (reprinted in 2002 as The Design of Everyday Things) describes human-centered design as “an approach that puts human needs, capabilities and behavior first, then designs to accommodate those needs, capabilities, and ways of behaving” (1988, p. 8). Ideo.org expands upon this idea by establishing the importance of empathizing with end users in the design process: “Human-centered design is all about building a deep empathy with the people you’re designing for; generating tons of ideas; building a bunch of prototypes; sharing what you’ve made with the people you’re designing for; and eventually putting your innovative new solution out in the world” (n.d., para. 1).
Thus, if we think of HCD as being all about the design of screens, keyboards, mobile devices, we’re missing a big piece of what human-centered designers bring to a project. HCD, in practice, is as much about research as it is about design. Perhaps the profession has been saddled with mentioning the “D” of Design in its name, but failing to call out the “R” of Research. Yet, research is an essential component of HCD. Interviews with our business stakeholders tell us what they need. Observation and interviews of people who could benefit from a product or service help define what to build. Ongoing contact with and feedback from those affected by the product helps inform decisions all throughout development.
Second, let’s think about the term human. There’s a reason many of us refer to ourselves as “human” centered designers rather than “user” centered designers. Human is a superset of both user and customer, the latter two being the most obvious consumers of the things we typically create. By contrast, human includes others affected by a product, such as developers who interact with APIs, line-of-business managers who are responsible for ensuring the movement and consolidation of data in support of business processes, data scientists who consume the data, and many others. In short, ultimately, no matter what tools or technology we build, there is always a human somewhere in the equation. This broader view of HCD makes it obvious that HCD is critical on all development projects, including data projects.
Third, let’s look at what we typically consider an interface. A broader view of interface includes any of the multifarious ways a human interacts with technology. An API is an interface. A CLI (command line interface) is an interface. A dashboard only seen by data scientists to help them understand the movement of data through a pipeline is an interface. Once we expand our concept of the interface, it becomes apparent that human-centered designers can bring great value to data projects.
Finally, let’s think about the people who create backend systems. Large enterprise systems—particularly those that handle large amounts of data—are extremely complex. They are accessed, maintained, monitored, enhanced, and supported by many people functioning in a variety of roles. Communication and empathy gaps are common among individuals who work with such systems, despite the fact that the use and function of the system is a shared, common goal. The conduct, documentation, and communication of HCD research helps bring empathy and understanding to those who are responsible for creating the system.
Thus, to summarize why it is important to apply HCD to data projects, it boils down to two main objectives:
- to understand the experiences, behaviors, and needs of the people who use and are otherwise affected by the system, and
- to bring understanding and alignment to the people creating the system.
With this background, we held the first HCDAgile for Data Summit at the offices of 1904labs in St. Louis, Missouri in October 2019.
Summit participants were selected based on their experience with this topic. Prior to arriving, they were polled about areas of interest for further discussion during the meeting. We identified the three top choices; during the Summit, we divided into three breakout groups focused on the following, respectively:
- How does HCD research differ when applied to data projects?
- How does an HCDAgile for data approach affect business and development processes? Which tools and approaches most effectively leverage the role of process in product development?
- What types of visualization (dashboards, maps, metaphors) are most useful for data projects? What is the role of visualization design in data projects? What are some considerations when creating visualizations?
Following the breakout session, the three groups reconvened to share their observations. We integrated ideas across the groups to develop an initial framework of best practices and ideas for follow-up discussion topics.
Here are the observations, insights, and guidance from experienced practitioners on how to apply HCDAgile to data projects.
Research
The research breakout group identified two primary elements critical to the HCDAgile process to be effective in a data project: high quality relationships across stakeholder groups and application of appropriate methodologies.
- For research on data projects to be effective, human-centered designers need to form partnerships and alliances with a number of constituencies.
- The organizations we support are often new to working with HCD, especially if they focus primarily on back-end/data projects. At the same time, most human-centered designers are new at applying HCD to data projects. Rather than being an impediment, it is an excellent opportunity to share empathy. By being transparent, honest, and humble, human-centered designers can foster effective partnerships; “we’ll learn this together” can be a unifying message.
- In many companies, IT and the business are notoriously unaligned. By bringing together technology considerations and applying them to business goals, HCD can provide the “glue” between these two groups of stakeholders. HCD can translate business needs into technology goals.
- The Product Owner is arguably the number one ally we need to enlist to ensure superior outcomes. The Product Owner, in the HCDAgile model, is the final word on all product decisions. Even on very large projects that may have multiple feature owners, or even multiple people with the title “PO,” it is important to designate/identify a single point of contact/seat of responsibility representing the business. A close relationship between human-centered designers and the PO ensures that the needs of the business are always top of mind in all HCD activities.
- Transparency, humility, and empathy are key to forming all product partnerships, but perhaps no more so than when the product is highly technical in nature. Most human-centered designers do not have a technical background. Rather than trying to “fake it,” they need to be clear that they do not have deep technical skills, such as decision science or data engineering, and thus may not understand all of the technical implications of what they hear during research activities.
- They need to ask for help; that is, they need to partner with someone who has those technical skills to help plan, conduct, and interpret the results of research activities. In addition to helping understand all of the technical implications, technologists will also come to feel genuine ownership in the HCD activities and will be more committed to making sure HCD is engaged throughout the project.
- Research methods for data projects must be appropriate to the task at hand.
- Surprisingly, human-centered practitioners use virtually the same research methods with data projects as with traditional projects. Contextual inquiry, personas, journey mapping, story mapping, surveys, and other traditional research methods are as useful, if not more so, with data projects.
- With regard to research methods, what may differ are the roles of the humans involved in the project. Rather than consumers, employees, and other typical “end users,” the humans in data projects are more likely to be developers, data scientists, data analysts, systems maintenance professionals, business managers, and others. They may not use typical interfaces or may not have a choice as to what they can use to do their job, but they warrant the efforts of a human-centered approach, and the success of a project relies on their success.
- HCD professionals, in their efforts to bring internal alignment to their team, will likely find themselves performing more internally-facing activities than with typical projects, such as facilitating design thinking and other types of team workshops.
Process
The HCDAgile Process breakout group addressed two closely related questions:
- How does applying HCD and HCDAgile / Agile UX to data projects affect your stakeholders’ business processes?
- How does engaging HCD on data projects change a typical development process?
In addressing these questions, the team identified five critical points to keep in mind in designing processes around data projects.
- Using HCD to create views of data (for example, the As-Is and To-Be data journeys) can help business stakeholders visualize how data moves from point to point across the business, and how that data support business objectives at each step. The job of the human-centered designer in this context, then, is to clearly communicate how data affects a business process.
- Visually mapping the As-Is and To-Be journeys of business data is important for a number of reasons.
- It provides a baseline from which to determine whether the project is making measurable progress toward tangible business goals. Gathering and communicating objective measures is an important role of the human-centered designer on data projects. Arming ourselves with ROI, value stream mapping (VSM), and other tools can show how data movement and consolidation can enable business processes. Human-centered designers engaged on data projects should learn how to measure ROI to show how data can deliver value, perform VSM to show how data moves through a business process to enable business goals, and otherwise communicate the value of improved data movement and consolidation.
- Alignment of key project stakeholders is critical to project success. IT and business stakeholders tend to be very different personas, with very different mental models, goals, and objectives. Yet, if data do not ultimately serve a business purpose, then no matter how efficient its movement and consolidation, it is not going to provide value. Using journey maps to communicate experiences with the system to both IT and business stakeholders can improve alignment of these key constituencies.
- One of the most important elements to the success of data projects involves trust. Stakeholders must feel secure that the data upon which they are hinging their decisions are reliable, accurate, and timely. Human-centered designers engaged on data projects should focus on assessing and communicating the trustworthiness of the data. Understanding the processes by which the data are handled and consolidated, and communicating this information can help developers improve their delivery processes and help stakeholders trust the data itself.
- Human-centered designers must become advocates for including HCD on data projects.
- Because data projects have no obvious user interface, stakeholders often resist incurring the cost of engaging HCD professionals.
- Many business and IT stakeholders also resist against the time expense of measuring the As-Is state of the data, arguing that it’s not necessary because the As-Is state will no longer exist as a result of the project. The human-centered designers need to explain—using case studies, ROI calculations, value stream mapping, and other tools—that “you have to slow down to go fast.”
- Human-centered designers should always be teaching. HCD is still a relatively young and often misunderstood craft. Human-centered designers, in addition to engaging in and communicating the findings of HCD activities, should provide an element of education. For example, human-centered designers should explain the following:
- Why HCD takes time, and why that time is worth the investment. By using case studies and ROI analysis, the value of HCD can be brought into the everyday understanding of everyone involved on the project.
- How what is learned in HCD activities translates directly to product outcomes. For example, human-centered designers can use journey maps to show how the team’s activities move the needle on identified pain points.
- What stakeholders should expect from HCD, both in terms of specific cost and benefit. For example, human-centered designers should represent their activities in product plans/roadmaps and in the backlog.
- What should be on the HCD activity agendas, the desired outcomes, and the next steps. For example, every meeting should have a crisp, targeted agenda and should be followed with a rollup or topline report.
- Why some of the most valuable outputs of HCD may not just be deliverables, but alignment and a shared vision. By articulating this aspect of HCD, stakeholders will recognize that HCD is fuel for the engine of development.
Visualizations
The Visualization breakout group focused much of their discussion on data dashboards, a typical deliverable from data projects, but also addressed general principles of how to best use visuals to communicate about data. They arrived at three key points of guidance for using visualizations.
- When using visuals to communicate about data—keep it simple.
- Aesthetic appeal is not necessarily important when creating data visualizations; however, effective, clear communication is critical. Sometimes a simple sentence, or even a simple box containing a number, is enough to communicate the data to those who need it.
- Rather than extensive visual embellishment, the visual design should focus on optimizing the layout of data representations so its consumers can easily understand and consume the content. A strong layout tells a story about the data and helps the consumer understand the big picture, while allowing them to access the details as needed.
- Everyone wants a dashboard. The practitioners at the Summit generally agreed that once the humans affected by the product see a data dashboard, they (a) immediately want one and (b) want to customize it exclusively for their own persona.
- Data projects often have a large number of personas—often more than a typical project. And each persona may benefit from a unique view of the product’s data. For example, on the IT side of organizations, there may be data scientists and developers who need to see many details about the data. On the business side, there may be a CFO, line-of-business managers, marketing managers, business analysts, and many others who need to see very different views of the same data or different data altogether. One of the Summit attendees called the demand for so many different dashboards “terrifying.” Thus, research that identifies key personas and their wants and needs is a critical prerequisite to creating effective dashboards.
- Once the personas are identified, human-centered research should focus on understanding the key metrics valuable to them. One Summit attendee noted that currently, developers often create dashboards in a vacuum. They make assumptions about what should be included in various dashboards, rather than knowing for sure. HCD can bridge this gap by helping developers know what to include and how it should be represented.
- Metrics specific to any given product should be identified and, if useful to the key personas, included in dashboards and reports, either in a primary view or a drill-down view, depending on priority (importance, frequency of use) and design style.
- The most common KPIs and data statuses for data may include volume, quality, speed, status, provenance, and lineage.
Carefully researching the personas and identifying the contents of a limited number of distinct dashboards is important to making the project manageable for designers and developers. Rather than taking the time to create every variant of a dashboard, many of which will not be used, it may be valuable to follow a variant of the Pareto Principle; that is, make sure that 80% of the contents of a couple of key dashboards will be useful to 80% of the humans consuming them, and then customize a smaller amount of dashboard content.
- Usability for data projects is often defined by how useful and usable the data visualizations are.
- Although data projects often do not involve designing typical user interfaces, human-centered designers can still focus on product characteristics like ease of use. For example, it’s possible to test the usability of a data visualization by prototyping a dashboard containing “dummy” data. Then by using think-aloud, you can determine whether a persona can understand the data, drill down to get more details, and use the data to make applicable business decisions.
- Visualizations such as journey maps depicting the journey of the data can be used to help developers focus on alleviating paint points within a data pipeline.
- The team should always remember that a dashboard or other visualization is not an outcome—it is a means to an end, not an end in itself. Designers, developers, and consumers of dashboards should always focus on the data: Which data is important, how can it be presented so it is usable, and what business outcomes are supported by having access and visibility to the data?
Conclusions
When considering how to best apply HCD to data projects, there are clear differences from how we apply HCD to more traditional user- and customer-facing projects:
- Data products are more technical in nature and may not have a user interface that is obvious to human-centered designers or business stakeholders.
- Our users may be technically-adept, back-end-focused technologists; data consumers; data analysts; and others who do not fit the profile of typical users.
- Alignment of the various people and teams who are working to create a back-end system becomes a critical focus of the HCD practitioner.
- Human-centered designers can’t go it alone. We need to support and partner with our technical colleagues to help us plan, conduct, and interpret the data that drive the process.
Yet at the same time, applying HCD to data projects is not much different than what we always do.
- Our skill set positions us to tease out requirements, gain alignment across constituencies, focus on key personas, define critical success criteria, and measure progress toward a goal using methods we are familiar with, and which we use with more typical end-user-oriented projects.
- Our ability to communicate what we do and why we do it via visualizations and provide clear explanations of process and value, position us to accelerate and facilitate technology enablement.
- We focus on the human elements of trust, transparency, and empathy to provide the glue that brings all elements of a project together.
In short, human-centered designers have the skills needed to engage in data projects; all that is needed is a pivot toward more internal-facing activities.
Next Steps
The HCDAgile for Data Projects Summit was the first in what we believe will be an ongoing discussion about how HCD can meet the needs of a changing set of technology needs. Applying HCD to data projects means that we can ensure, as professionals, that we are helping to build the right things the right way.
Additional webinars and Summits to address other aspects of this important topic will be held in the near future. If you are interested in this effort, please contact the author at crighi@1904labs.com to be included in this ongoing conversation.
References
Ideo.org (n.d.). What is human-centered design? Retrieved from https://www.designkit.org/human-centered-design.
Norman, D. (1988). The Psychology of Everyday Things. Basic Books.
