Data Models describe what will form the basis of the structure of the product. During the second phase of Goal-Directed Design (GDD), the team creates models describing the data from their research. One of the most critical is the persona which describes the users. Data Models are another and describe how the users’ mental models integrate together.

Diving in to Data Modeling

Data object types are the atoms of a Data Model. “A data object type is a species of thing a user can create, manipulate, or look for, such as a file on a hard drive, a person in a contact list, or a store in a shopping mall directory” (Goodwin, 2009, p. 428). For digital products, users see these on a screen. In other disciplines like service design, the data object type might be something physical, or even a sound you hear. It is a noun of which there can be multiple instances. Data Objects represent what the user needs to see in the interface as opposed to the functional needs that the user must be able to do. “I move this candidate over into the list of passed background checks.” “Candidates” is a different group of people than “Employees” or “Applicants” and has its own definition and set of attributes. In the same way, “List of passed background checks” differs from other types of lists. Sometimes the team must invent new object types that don’t currently exist in the persona’s mental model. See pp. 428-429 in Designing for the Digital Age for more.

During the research phase, record these data objects. Kim Goodwin suggests using a spreadsheet tracking the following information.

• What users call the data object
• What it is (Definition)
• How it relates to other object types (Relationships)
• What users can do with it (Actions)
• What states it can be in (States)
• What attributes it has that your personas care about (Attributes)

Constructing and Using a Data Model Problem: During the design sprint, we came up with the idea of providing pre-built workflows for common manual processes. Through usability testing, we discovered the difficulty of understanding different possible flows. But we didn’t do the needed Data Model. Cue the ominous music. This led to some confusion when it came to design. Later, I did a card sort + tree test to organize each flow on the initial screen. This could have resulted in a data model with the data object of a “workflow.”

• What it’s called Doing a manual check, Manual Check and Void workflow
• Definition A series of steps a client takes to accomplish certain outcomes such as fixing a mistake or recording some types of pay with recorded taxes
• Relationships
  • Applies to one or more employees
  • Includes one or more actions to either record various types of payments or voids
  • Reverse money previously taken.
• States
  • Incomplete
  • Waiting to be pulled into payroll
  • Completed
• Actions
  • Start
  • Select employee(s)
  • Choose adjustment
  • Choose an amount
  • Choose a check
  • Delivery method
  • Attach to payroll
• Attributes
  • Name
  • Description
  • Steps or stages (take an action)

A complete data model contains many such entries. Some of the items mentioned here are their own data objects and would be in the spreadsheet. For example, each individual flow, the ways to add money, and the ways to void or take away money.

Constructing the Data Model

Goodwin suggests a few ideas when creating a data model. First, put down even the mundane items to iron out what each item means. This helps clarify information later on so that designers and stakeholders have a clear picture of users’ intentions. Second, look at the types of relationships between data objects. Think about the mental model objects found during the research phase. These may be relationships like many to many, many to one, one to many, one to one, hierarchical, or temporal. Third, the attributes may be good candidates to populate a database. Finally, revisit this after each interview, or edit during synthesis, scenario writing, and design. This document will evolve as the product matures.

Goodwin may be reflecting on James Spradley’s semantic domains. In his book The Ethnographic Interview, he describes analyzing interviews to makes explicit the domains that exist in the field. A domain contains a cover term, a semantic relationship, included terms, and a boundary (Spradley, 1979, 102). In his work, he worked to discover the language that the field uses. This is what designers do with mental model objects and data objects, and is appropriate to consider here. Spradley’s semantic domains help in thinking about the relationships between data objects. I’ve listed them here for convenience.

1. Strict inclusion – X is a kind of Y
2. Spatial – X is a place in Y, X is a part of Y
3. Cause-effect – X is a result of Y, X is a cause of Y
4. Rationale – X is a reason for doing Y
5. Location for Action – X is a place for doing Y
6. Function – X is used for Y
7. Means-end – X is a way to do Y
8. Sequence – X is a step (stage) in Y
9. Attribution – X is an attribute (characteristic) of Y

A documented data model is one crucial aspect to speed design as it eliminates the need to speculate on the make up of the system. Designers can guide future designs by bridging the gap between fieldwork and design. This essential model benefits UI designers, Product Managers, Developers, QA and leadership by describing the words used to describe the domain.

The place of data models in Goal-Directed Design

The data models described here differ from the kinds of data models a developer would create. In those, developers are looking to map out the database structure. Though the data models designers create may later help inform a developer’s model, they are from the personas’ perspective(s). Designers derive data and functional needs from the model to inform the design.

Though modeling is its own phase of GDD, data models fit in throughout the product lifecycle. The design team begins the work during research and continues to flesh it out as they uncover new information. Doing this work pays dividends by answering questions when the design pair works out the solution.

In conclusion, a documented data model can be an invaluable tool for designers, developers, project managers, quality assurance teams, and leadership alike. It provides a clear understanding of the data objects and how they relate to each other, making it easier to design user interfaces that meet users’ needs and streamline the development process. Additionally, having a documented data model helps to ensure consistency and accuracy throughout the project’s lifecycle, and can even serve as a reference point for future iterations or updates. By taking the time to develop a well-defined data model, teams can save time, avoid confusion, and create better products that meet the needs of their users.

Read More on Data Models

Recently came across this article that describes additional types of data models.

A Guide to Data Modeling & The Different Types of Models (segment.com)

References

Goodwin, K. (2009). Designing for the digital age: How to create human-centered products and services. Wiley Pub.

Spradley, J. P. (1979). The ethnographic interview. Holt, Rinehart and Winston.