Business Value
My end-to-end process building a tool for dynamic variables
In my role as one of the product designers on this project, I documented notes and decisions into Miro early on to promote high level visibility and communication with the team. Collaborating closely with my design partner, I set up working time for us to understand the problem space and user needs. To start, we did qualitative research with appraisers, mapped out current behaviors and user flows, and gathered insight into the contents appraisers used. We worked together sharing and sketching ideas (sometimes two heads are better than one!) and mocked up prototypes for user testing. Engineers were involved often as always as this part of the work included understanding technical implementation of creating and adding dynamic variables that would make the most sense to users.
In 6 weeks, we delivered a tool to create and add dynamic variables into the WebApp where we had 250+ unique contents created.
initial research & starting out
Our system had 20 static variables already available. I spoke with appraisers and found that they weren't aware of static variables in WebApp's system. So, we knew that we needed to make this an accessible feature for users. To start, the team and I wanted to ensure that current and newly created variables would align with users mental model of how they're referencing appraisal data.
Users have said:
They think about them in terms of where they live in the WebApp (sections or pages).
They reference the data by their value (ie. 123 Main Street = Building Name).
They have a shared document for external real estate materials they sometimes will copy and paste into the report.
"Chips" is the word appraisers used for the static and dynamic variables used in a report. After a survey to gauge the best simple term to use to reference dynamic values, appraisers felt the word "chips" is easiest to use.
Based on that, we started with a thought exercise of a grocery store model to understand the relationship of how items are identified and labeled and ultimately found and used. Then we mapped it to our current "chips".
Mapping out the flow to understanding how to manage and surface dynamic values.
Almost all data fields within the WebApp can be created as a dynamic variable to be reused. This meant that it'll be hard to easily surface the correct information without unique attributes and grouping. Knowing that users reference items by value and page sections, we proposed to add tags to help surface relevant chips.
How might we categorize and group data:
The data can belong to multiple groups (create flexible tagging system).
These groups determine how the information will appear.
Users can reference the value or display name to surface chips, so it's important to clearly make it a requirement when creating chips to define the data path and tags.
Some attributes to be considered
Human Readable Name (Display name or label of the chip)
Value (What human readable name refers to)
Data path (Where the data comes from)
Tags (Group placement for chip)
Format (Styles the chip)
Some areas of unknown include changes to report when a chip is modified, search functionality for chip bank, ease of creating chips.
Taxonomy and meta data tagging of content.
From the taxonomy, we started to mock up how users might interact with the chips. This would inform what we need for low fidelity sketches and mockups. This also aligned product and engineers on the functionality of chips creation, storage and user actions. The goal for creating chips with a storage bank is so users can generate it themselves without relying on engineers. Therefore, it was important to make it simple to understand. For example, a field like formatter might be confusing for users. To guide users, I added helper text and also worked with engineers to populate the field based on the data path we get on the backend.
Mapping out the path of finding and using the chip.
research: user testing
Midway into the project, requirements changed. Instead of all users to start, managing directors of teams and product would be the ones to create chips. I reached out to the group to make sure that terminology were clear and worked with our lead researcher to quickly run through best practices. A loom video was created afterwards on how to use the Chip Bank to create and store new chips.
We prototyped and tested with users on how to add chips within report.
We conducted usability test to learn how users were reviewing information surfaced when they're searching for a specific chip in the UI. We didn't want to overwhelm users with irrelevant attributes.
In a card sorting study, users listed Human readable name (label), Value and Group as the most important information.
2
Ability to create and
modify chips
Users need to have flexibility to create and modify the data.
3
Make searching for a chip to add to a component quick.
solution
We aimed to build an intuitive mechanism for users to register new chips without relying on engineers. This application needed to be user-friendly, allowing easy creation, editing, and updating of new variables.
Users rarely used the current chips because they were unaware of it. To make chips accessible, I improved the UI of the components to inform users that using "=" key will prompt the chips modal to open.
Why "=" key? This was the original prompt key because it was easy to access and usually not used in a report. Given more time, I would've looked into whether this was the best key command.
The main objective for chips creation and storage was to empower users to generate and adjust their content. Engineers and designers collaborated closely on the technical execution and user interface of the chip bank.
The interface needed to be straightforward and informative.
After reviewing the navigation of the WebApp, I proposed building the Chip Bank within the CMS section. This centralized all the content creation tools.
Instead of erasing created chips which may cause disruption in other reports, chips are merely archived and will not appear in the chip search interface.
Ultimately, the value of the chips to users is to easily find and input the content.
They needed the ability to remove or update the chip within the components.
Keeping error states in mind, if chip has a broken value, the system should inform users that the chip is missing information.
Outcome
Content were easily shared and reused in reports
After launch, we started with giving Managing Directors access to create the chips needed for their team. This made it easier in the beginning to get started without overwhelming the system.
We had about 250 unique content created in the system.
From Pendo analytics, contents were reused across multiple users 850+ times.
Impact since launch (as of March 2024)
Thieman • 2024
Made in New York.