How to create a Terms and Statements Inventory and streamline your UX process
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?
How can experienced professionals debate, for example, the meaning of layout? Well, they actually can and will. After asking some of my peers about it, I found out that this is a pretty common issue that seems terribly underestimated.
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
- You set a common language within the team so no more time and work is wasted on miscommunication between members
- 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?
The Terms and Statements Inventory is useful every time you start designing a new feature or an entire new product from scratch.
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.
How do you build it?
What I do first is make a list of all the main modules of the product. For example, if you’re designing a booking mobile app, some of your modules might be the user profile, the destinations or the bookings list.
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?
The Terms and Statements Inventory is a document. As long as it contains the terms and statements of your product and is easily accessible for all your team members, it can look in any way you want to: Google Docs document, Google Sheets document, Axure link, Sketch file, Photoshop file, Word document, Excel document etc.
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
At the beginning of this article I was mentioning a product meeting which turned into a debate about terminology. Following that, I went on and built my first official Terms and Statements Inventory, discussed it with my teammates, iterated it a few times and, finally, agreed on a final version.
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
Designing a great product is not only about finding the perfect idea and the best implementation but also about conveying them to the members of your team. As a UX or product designer, you need to get involved in improving the experience of your team work because that is going to be reflected in the experience of your product.
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!
Please click the ♡ button if you found this article interesting, so others can find it too. If you want to keep in touch, follow me on Twitter and Medium or visit me at davidteodorescu.com
