Vertis helps companies make data-driven workforce decisions by combining internal information with dynamic market data.
Vertis combines internal workforce data with external, dynamic market information to help companies make informed workforce decisions. The product was new but far from unknown. Engaged users at companies like WeWork, Alteryx and Airbnb were using Vertis to power important decisions about new office locations, hiring hotspots and retention in a post-COVID business landscape.
Users enjoyed the powerful data capabilities in the product and wanted to expand its use into other areas of their workforce decision-making, further replacing other tools like PowerBI and Excel. Each customer had needs as unique as their business’s configuration.
In August 2022, I began working with the Vertis engineering team to build out their next-generation reports as well as a design system to unify their data visualizations going forward.
Interviewing engaged users to build a clear understanding of the problem dimensions.
Collaborative Solution Definition
Defining solution requirements, timeline and usability goals with the team.
User Flow Mapping
Defining user movement through the product to accomplish the goals established.
Developing user flow into layouts influenced by our usability and information density goals.
High-Fidelity UI Design
Evolving wireframes to styled mockups with Vertis branding and responsive behavior.
Interaction Design & Prototype
Designing key interactions and animations. Polishing Figma prototype to final form.
Writing scenarios and moderating user tests with five new and existing users to evaluate solution and identify usability issues.
Reworking interactions and layouts that fell short of usability goals. Finalized user-validated product designs for handoff to engineering.
Unifying component styles and defining chart specifications to reinforce brand and lay foundation for future features.
Painless starts to new reports.
With the new feature designs, users can create a report from a template like Commutes, which comes loaded with a set of tiles and pulls from the last-used data sources. Users can easily swap data sources and rename the report for lightning-fast report customization.
To define the dimensions of our design problem, we needed to talk to the two major categories of users that Vertis targets and serves:
Real Estate Companies
Customers like WeWork needed a tool for their enterprise sales team to visualize customer location options and communicate the impacts on employee commutes. These users were primarily interested in comparisons and commutes.
Customers like Alteryx wanted to open new offices in new markets. As more tech companies implemented flexible work policies, they needed to open offices that minimized commute time for existing employees while also attracting competitive talent.
I led five hour-long one-on-one interviews with existing users from both categories. We discussed what was working and what wasn’t, as well as their business needs, role requirements and the tooling for data analysis and visualization.
Here’s what we learned:
Users needed more flexibility
Though our users’ needs were similar, they were just varied enough to make a one-size-fits-all solution impossible. Customizability would be the way forward.
Users valued Vertis for its approachability
Our users were comfortable with Tableau and Excel, but they appreciated Vertis for its out-of-the-box visual style and approachability for non-technical stakeholders.
Users loved Vertis’ visualizations... but not its data manipulation
Vertis excelled at beautiful data visualizations but lacked filtering operations that would make data easier to manage.
Users wanted to share reports
Because Vertis’s visualizations were approachable and powerful, they were great tools for sharing to customers and stakeholders who were less comfortable in the data. Users were frequently dropping screenshots into presentations, but lost interactivity in the process.
Users were doing the same set of data tasks over and over with different data sets
The product only allowed one data set in a report at a time, but real estate users in particular wanted to save reports for different data sets.
I know how to use Tableau, I could do all this there. I use Vertis because it’s not Tableau. ....It already looks good, easier to look at, the commute maps are incredible. It’s easier to understand and it takes less time. But sometimes I end up in other tools anyway to get this one piece of information, and I have to paste all these screenshots into a new file to share with customers.
Defining the Solution
Our research gave us a clear shared idea of which user problems were the highest-value to solve in the next generation of reports. With our shared understanding of the user problems in place, we articulated our direction and clearly defined prioritized goals for the next stage of work.
We set out to create composable reports that allowed more granular data manipulation without compromising the product’s ease-of-use. We needed to make Vertis more flexible and customizable while keeping it approachable.
Users would be able to click into individual tiles on a report and customize the visualization type, data displayed, and labels. Tiles could be individually added and removed.
Easily create new reports with templates
Users would quickly and easily create new reports using templates to get them 80% of the way to their data destination. They can then refine reports with tile customizations. Users would also be able to define their own templates to streamline repetitive tasks and allow them to keep hold of old information.
Data filtering and management
Users would be able to adjust and filter datasets on both the report level and the tile level, allowing granular customizability for users who needed it without forcing those flows on users who wanted a simpler interaction.
Share-mode for interactivity without disruption
Users would be able to easily share reports with stakeholders and customers, allowing those recipients to benefit from Vertis’ interactive data exploring without the risk that they would accidentally disrupt the report data.
Multiple report management
Users would save and manage their reports so they could return to them over time, make comparisions and keep share links active.
Once we determined the best path forward, I created a solution flow diagramming that would allowed us to consider the user journey more carefully and determine technical implications of our decisions. Initial development of this diagram too, two days, and over the next week we revised it several times as team reviews surfaced additional technical considerations.
User flow diagram
The user flow diagram is an invaluable tool for deeply considering application flows before investing time and resources into wireframe development. These diagrams lay out all possible user journeys in a product area and drive great conversations around scope and technical requirements.
By the end of week three, the team was fully aligned on our scope and desired user journey. The software architects set to work on API changes that would support our design solution as I proceeded to create wireframes that placed our user flows into a layout context.
I began to systematize the layout of our new reports using wireframes strung together into low-fidelity prototypes to show the team options on how we might build our new flows into the UI.Starting with wireframes made it easy to focus team attention on matters of content, structure, flow and information density rather than prematurely debating the merits of different UI treatments.
Separating our visualizations into visually distinct tiles allowed us to establish a design language that could persist across reports and generalize certain interactions, helping users navigate more intuitively.
At this stage, I also ran a quick UX audit of the existing system to flag any accessibility issues and component inconsistencies as well as identify any potential issues with information architecture and navigation hierarchy that would need refactoring in our new direction.
At this stage, we made the key layout decision to use a dismissible side panel for filtering and customization. In line with our approachability imperative, it was natural to “hide away” our deeper customizability in a side panel that appeared only when a user indicated they wanted a more substantial interaction with a tile’s contents.
In the wireframe stage, we explored initial layout system investigations around visualization tiles and sidebars. Wireframes restrict the design to mostly grayscale and shy away from graphical elements, allowing us to focus on the content and structure of the view.
With wireframes corresponding each step of the user journey, I was able to stress-test the layout for all of our primary needs as well as edge cases. This way, the team could travel through the full user journey in low-fidelity and make changes to improve the task flow before moving onto styled mockups.
At the end of two weeks of wireframing, the team was in agreement on layout, content and key interaction flows for our new customizable, sharable reports. With these key decisions in place, I proceeded into the high-fidelity UI design stage.
High-Fidelity UI Design
With all our detailed wireframes in place and the interactive components already systematized, creating our high-fidelity design was straightforward and allowed us to focus on the felt experience of the product as well as accessibility and quality of data visualization.
We re-evaluated our color palette for accessibility and made some key brand visual decisions that we propagated throughout the system components, then dialed in the visual balance of our spacing to produce a polished, balanced UI that fixed many of the disorganization issues from the earlier product.
Customize reports tile-by-tile
Users can add tiles anywhere and choose from the full visualization library, made more navigable with data filters and text search. Duplicate and modify existing tiles, delete tiles, and drag tiles to reorder them in the UI.
Granular data filtering when you need it
When users drop in a tile, they can immediately visualize their default report data rather than needing to “build up” the visualization contents. Clicking into a new or existing tile presents opportunities to customize the visualization, change the data source, or add filters scoped to this tile only.
Powerful dataset filtering
Additive filters allow users to look at the information that matters most, filtering by any data dimension available in the source file. Users can create filter sets whichever way they work: top-down (defined and then applied) or bottom-up (applied to an individual tile and then applied elsewhere).
Visual data summaries
It’s easy to see which parts of your report use which filtered data sources. Visual summaries show which tiles use which filtered data sets, and it’s easy to propagate filter sets to new tiles and reports.
Because we chose to protect the product’s uncluttered approachability by “tucking away” functionality like filtering and the tile library on desktop, it was essential that we provide adequate affordances for users to discover these features in the application. We chose hover interactions after observing how our users habitually explored interfaces with their cursor. Since the product was desktop-only and impractical for use on mobile devices, the hover-approach was feasible and accessible as long as we also built in similar affordances for keyboard navigation.
While suppressing functionality from view introduces some usability risks around discovery, the team was in agreement that this approach was worth the risk because it allowed us to keep an uncluttered interface and protect the “easy” feeling that users love about Vertis. We hypothesized that these features would still be discoverable for unfamiliar users and included this hypothesis in our user testing.
The hover affordance on report tiles allowed us to keep our UI streamlined and approachable, but came with discoverability risks. We took care to investigate this approach further in usability tests.
In parallel with the feature UI design, I began developing a new design system for the product team that would improve component consistency and accessibility as well as increase development efficiency in the future. Like the feature designs, the Vertis design system started in a wireframe stage and developed in fidelity as the UX requirements became increasingly clear.
Because of Vertis' focus on data visualization, the design system included an expanded color palette to ensure readability in layered bar charts. It also included a full documentation of chart types and standardized legends and tooltips.
Though creating a design system in parallel meant a slight slow-down at the start, the time investment paid off in rapid acceleration as we expanded and iterated on the UI designs.
A slice of the Vertis design system
Figma makes it easy to build systems in parallel with the usual design process, and spending a little extra time documenting components along the way has numerous payoffs throughout the current development scope and future product lifetime.
Resolving existing inconsistencies.
The Vertis product had come together quickly without comprehensive design oversight. Consequently, we had a few different styles of components like dropdowns and buttons scattered over the site, taking away from overall polish and usability.
Users are able to navigate a pro tool much more effectively if there’s a consistent design language. I find this is most important when using color to indicating interactivity on certain components rather than using color with an eye towards aesthetics alone.
Addressing accessibility issues.
Contrast issues with the product’s color palette extended to interactive components. Systematizing the design allowed engineers to create standardized components that were not only visually enhanced, but also minimized the need for ad-hoc components that might lack important standards for screenreaders.
When we made visual tweaks to components after the system was created, it was trivially easy to propagate those changes throughout the entire product — both in the design files and the build itself. This is essential to keeping a product looking “modern” over time without incurring huge time costs on facelifts.
Focusing attention on the design system up-front allowed space to think about necessary variations, reducing the need to “go back to the drawing board” for individual components later on when we were focused on building out new features. There’s a balance here to avoid premature optimization, but there were certain variations we knew we would need in the future.
Using engineering time wisely.
Engineers could build out UI components while waiting for the feature design to be ready to build. When the feature was ready for development, engineering time time was reduced significantly since these components were ready to go, and the team didn’t feel pressured to rush these important interactions in order to get the feature out the door. This improved overall product usability.
User Testing & Iteration
After high-fidelity prototypes were ready, we went to evaluate our solution by presenting the prototype to new and existing users in structured user testing sessions.
A tasked approach to user testing is far better than the notoriously unreliable self reports (”Do you like this? Would you use it?”), but the nature of our composable reports feature — flexible, customizable, individualized — made this difficult to test in a linear Figma prototype. However, this feature was so foundational to the product’s future that we couldn’t afford to get it wrong just for ease of testing. I coded a custom prototype and uploaded it to GitHub pages to allow flexible paths in our usability test.
With the help of team discussion and input, I created a test plan with five information-discovery task prompts that were representative of tasks a user might face in their day-to-day work. The prompts were unguided and open-ended, allowing multiple approaches. This allowed us to approximate a realistic work environment over our Zoom testing sessions and see how users thought through the interface.
In addition to observing overall user sentiment, behavior and frustrations, we set out to assess the following:
- Sidebar discoverability. Could users figure out how to open the sidebar? Could they find the tile library and tile detail view necessary to complete deeper tasks?
- Filter usability. Could users navigate the application of filters? Did they understand and expect the behavior produced?
- Language clarity. Did users intuitively understand the language we established around “filter sets”, “tiles” and “library”?
- Flow usability. When users were in a problem-oriented mindspace, could they use our UI as a tool to accomplish their desired tasks, or was the UI an additional problem to solve?
We found that our tile and sidebar layout approach was usable and intuitive to every user, and the hover-to-discover approach to the sidebar caused no confusion or hesitation. Our language was clear to users and there was little confusion around navigation — with the exception of the tile library, which needed a more prominent affordance. Best of all, all six of our test participants were excited about the changes they were seeing.
This is really great, really exciting. I mean it’s exactly what we’ve been needing. Is it available yet? When can I use it for real?
Our test showed us a couple easy opportunities to improve the user experience before the build. First, we improved discoverability of report settings by adding a cog wheel icon to the button, which was a familiar pattern to our users. Second, we made the tile library more findable with a button at the bottom of the report — an affordance that wasn’t based on a precise hover interaction in the space between tiles. This solved the only two major usability problems we found in the product.
Overall, the test was a great success that validated our overall UX approach as a usable solution to the customer problems we identified at the outset. After quickly resolving on the usability issues identified, our feature designs were ready for development.
The new composable reports went into development shortly after usability testing concluded and went live in January 2023 to positive user feedback. The new feature also served as an important discussion point in product sales.
With composable reports in place, focus has now moved to building out the robust sharing features that we investigated in the initial user research. With the filtering and composability foundations in place, the team is also free to work on high-value and much-requested features like tabbed report pages and data comparison tools.
Vertis continues to grow rapidly and capture the interest of new enterprise customers nationwide. You can check out the product here.