How to create a Terms and Statements Inventory and streamline your UX process

David Teodorescu
Dec 8, 2016 · 7 min read
A sketch representing the connection between terms and statements

An essential guide for efficient UX and product designers on why, when and how to create and manage a Terms and Statements Inventory document.


Imagine a meeting in which several members of the product team try to agree on the features of a new platform. There are two UX designers, one visual designer, two front-end developers, a back-end developer and a project manager. Put together, that’s probably more than 60 years of experience in developing digital products.

We get to a point in which I start describing the design of a website builder, using a bunch of terms like templates, themes, layouts, presets and widgets. Everybody is nodding approvingly. All seem to understand the idea perfectly. Until one developer tries to conclude, mixing and replacing most of those terms in the process.

In less than 5 minutes, the discussion becomes a debate about terminology and everyone in the room is arguing on how we should name the components.

Why did this happen?

The fact is that an Agile setup gathers people from different tech backgrounds and each one interprets concepts from their job’s perspective. And this is even more evident when forming new teams, with members that haven’t worked together before.

Our own understanding of terms seems obvious to us, but nuances can produce a different obvious meaning for someone else.

For a designer, the mental representation of “layout” might be a visual schematic plan of graphic elements but for a developer that same representation could be a set of data arranged according to an algorithm.

To deal with this, I go through an extra step during my design process: the Terms and Statements Inventory. And it works.


Definition

The Terms and Statements Inventory (TSI) is a complete list of all the definitions for the terms used within the product and all the statements that describe the connections between those terms.

There are 3 main benefits for creating a TSI

  • It’s easier to create and understand design specs using terms and statements you all agreed on
  • New team members are easily introduced to an ongoing product, saving a lot of onboarding time

When do you build it?

Hopefully, when dealing with a new feature, you already have a TSI document created at the start of the project, so you only have to add the new terms and statements to the existing one. If not, start building it, the sooner the better. It’s never too late, especially if your product will have a fairly long lifespan.

Building a TSI is the responsibility of the product or UX designer. You’re in charge of making the first version, based on your initial design ideas. Once you have that, gather your teammates, discuss it and improve it based on their feedback. It might take several sessions to get to a form that everybody is happy with but it will streamline the development of the product once you’re all on the same page.

The terms and statements inventory is developed throughout the product’s life

How do you build it?

Each module has a Terms section and a Statements section. I start by adding all the components of the product inside the Terms section and write a definition for each one. Don’t hesitate to add obvious elements like dashboard or theme, for example, they’re sometimes the most debatable.

Depending on the moment you started the TSI, you either add them as you go along with your design (if you started it early), or you add them all, once your product is in a more advanced design stage (if you started later). I usually go with the first option because I find it easier to identify and define smaller groups of terms, as I build my design each module at a time.

Once you have your terms defined it’s time for explaining the connections between them in the form of statements.

While designing a product or a feature, we usually visualise the idea in our minds and start making abstract connections, trying to identify hidden relations between its components.

Statements are build by describing those relations you identified for your product. They are the written version of the designer’s thoughts.

Statements help you express and translate your idea into concrete rules and represent the textbook of your design. Not only do they help you crystallise your own vision, but they also make it accessible for your team members, the people responsible for transforming the idea into an actual working product.

How does it look?

Because of its flexibility, I often found myself building the TSI as a Google Docs document. It’s web based, it’s easy to create and easy to share.

In the end, it is just a collection of valuable information describing the components and the mechanics of your design. Content is what matters, form is secondary.


Example

Informally, I created similar documents for years, for most of the products I worked on, but I did it more as a personal organisation method not as a deliverable intended for the entire team. Better late than never, though.

To better understand the TSI, let me share some examples with you from a website builder I was working on then.

Examples of terms

Unit: physical presence of the business

Website: online presence of a Unit

Portal: online presence of an Organisation, linking to all the Websites

Theme: the visual style, composed of one Theme Layout, several Page Layouts, several Page Presets, one default Page for every Page Preset and a selected homepage

Theme Layout: the arrangement of the main components of the Theme (header, footer, content area, navigation)

Page: a Page Layout populated with Widgets

Page Layout: the arrangement of the Slots

Page Preset: composed of one Page Layout, allowed Widgets restrictions and initial Widgets

Slots: a placeholder for Widgets, with only one column

Widget: block of content

Examples of statements

Each Organisation has a different website Theme.

Any new Page is created based on a Page Preset.

Each website has Website settings, Page settings and Widgets settings.

Admins can change the main menu and footer menu structure by adding or removing Pages.

Slots have dynamic height.

Slots have unlimited number of Widgets.

The width of the Slots is adjusted according to the Theme.

Widgets have content that can be edited using the Widget settings or inline.

Widgets can be placed above or below existing Widgets.

Slot ownership can be restricted to a certain Admin level.

Once a Website was assigned to a user, a dashboard with website analytics is assigned automatically.

A user with multiple Websites assigned will have all websites analytics grouped in one dashboard.

Conclusion

You’re not going to build the product alone so the way you describe and argue your design decisions is as important as the design itself.

The Terms and Statements Inventory helps you minimise noise and focus on what matters. It sets a common language within the team and saves time by eliminating misunderstandings.

Integrate this step in your design workflow, adapt it to your team and product and enjoy the results.


Thanks for reading!

Read my other articles:

David Teodorescu

Written by

Senior Product Designer @Fitbit, writing about product design and psychology. http://davidteodorescu.com