Company background
Veras is a B2B workforce management platform for senior living communities. The platform included Scheduling, Messaging, Credentials, and Analytics. During this project, Veras was expanding into Time & Attendance and Payroll, which meant Settings needed to scale alongside the growing product suite.
As Veras added products, our settings architecture wasn't keeping up.
Veras was built organically, with new settings and features added as the product evolved. There was very little consistency in how Settings were organized. Related settings weren't grouped together, and configuring a community often meant jumping between settings in an order that didn't make much sense. Up until that point, investing in Settings hadn't been a priority, but as we were looking to ship several new products in the coming months, it was obvious our Settings experience needed an overhaul before it could support the level of complexity we were about to add.
Settings were complex enough that our customer success team decided that every new customer would get a 30-minute setup call where an onboarding specialist would walk through each setting to make sure everything was configured correctly before the customer ever started using the product. We had previously tried a more self-guided experience, and it had been disastrous.
When setting up the platform on their own, customers frequently made configuration mistakes that made the product much more difficult to use. One of the most common was creating dozens of shift templates instead of a small set of reusable templates. Instead of scheduling eight CNAs from a single template, communities ended up managing dozens of nearly identical templates. Filtering schedules became cluttered, moving employees between shifts became more tedious, and staffing budgets became unnecessarily granular. Customers would reach out in frustration, then a member of our customer success team would step in, delete the unnecessary templates, and help them rebuild the configuration the right way.
In redesigning Settings to be scalable for upcoming products, I wanted to make sure that same redesign would also improve customers' initial experience with the product and make it easier for them to configure their community correctly.
Configuring settings required a translator
I spent time sitting in onboarding calls, watching customers configure the platform alongside their onboarding specialist. I quickly realized a lot of the call wasn't actually spent configuring things, it was spent explaining what each setting did.
The specialist would ask for a community's bed count, and customers would often spend several minutes trying to answer a question that didn't actually affect the product. Bed count had existed for previous features, but in its current state it only created confusion and wasted time.
The specialist would ask how their areas were organized, only to realize the customer didn't know what an "Area" was in Veras.
The specialist would turn on features like Open Shift Pickup without even asking because nearly every community wanted it, while skipping over settings like Auto Publish because explaining what the setting did usually confused customers at that stage. Much of the onboarding call was spent helping customers make decisions they didn't have enough context to make on their own.
I watched dozens of PostHog recordings to see how people navigated Settings without a specialist there to help. One recording that stuck out was a user trying to edit a shift template. They opened a help article, went back to the product, read a little more, clicked around, and eventually gave up without contacting support. Their permissions settings were configured in such a way that the page they needed to edit was completely hidden from them, but nothing in the interface made that obvious.
The same patterns showed up outside of onboarding. Existing customers still struggled to find and configure settings on their own.
Before I began the redesign, I created an inventory of every setting in the platform, documenting where it lived, what it controlled, and whether it was still relevant. Looking at everything together, it was clear that years of product growth had shaped the Settings experience, leaving it disconnected from the way customers actually thought when configuring their communities.
Three themes came up consistently throughout my research. They became the guiding principles for the redesign:
- Organize around the customer's workflow
- Reduce unnecessary decisions
- Use consistent design patterns
Organize around the customer's workflow
The new information architecture followed the same order communities already used when configuring their operations.
- Community came first because it applied to the entire platform, regardless of which products a customer used.
- User Access followed so everyone participating in onboarding could access the platform and follow along as it was configured.
- Positions established the foundation by defining the roles and shifts each community would use.
- Areas built on positions and defined where each role worked.
- Budgets used positions, shifts, and areas to define the staffing requirements for each community.
- Compliance allowed for additional staffing rules for communities with more complex requirements.
- Staff Experience focused on the features employees would use every day, once the core scheduling setup was complete.
- Automation intentionally came last. It wasn't required for setup, but once customers understood how the platform worked, they could make informed decisions about what they wanted to automate.
Grouping related settings made the platform easier to navigate long after onboarding concluded. Customers could find settings by following the way they already thought about their community, rather than remembering where a feature happened to live.
The new structure also gave Settings a scalable framework for future products. Instead of throwing new products onto existing Settings pages, each product could be introduced as its own section with its own subpages.
Reduce unnecessary decisions
I focused on eliminating decisions that added little value during setup. Communities still had access to the same level of customization, but the most common path became much simpler.
- Infrequently used settings were moved out of the primary setup flow or removed altogether, helping customers focus on the decisions that actually mattered during setup.
- Defaults were driven by data rather than assumptions. I analyzed PostHog and Metabase data to identify which settings communities actually chose most often, then used those as the defaults for new communities.
- Progressive disclosure kept advanced configuration out of the way until it was needed. Most communities only needed a handful of fields to create a position, so additional options appeared only when customers chose to customize them.
The redesign preserved the platform's flexibility while reducing unnecessary decisions during setup.
Use consistent design patterns
Similar functionality often behaved differently throughout Settings. Save behavior, confirmations, layouts, and components had all evolved independently over time. My goal was to standardize those patterns so customers didn't have to second guess how the interface would work.
- Save behavior became consistent across Settings. Customers no longer had to wonder whether changes would save automatically, require saving the entire page, or update one item at a time. Once they learned how changes were applied, that behavior stayed consistent throughout the experience.
- Destructive actions followed the same confirmation pattern throughout Settings. Whether customers were deleting a position, area, or another configuration, the experience consistently communicated when an action was permanent and required confirmation.
- Related functionality reused the same layouts, components, and interaction patterns instead of treating every feature as a unique experience. The Staff Experience page brought together multiple scheduling features under a shared structure, making it easier to scan, compare, and configure similar settings.
By building on familiar patterns instead of reinventing them, customers could spend less time learning how Settings worked and more time configuring their community.
A foundation for future products
The redesign gave Veras a Settings experience that could scale alongside the platform instead of being reworked every time a new product was introduced. As Veras expanded into Time & Attendance and Payroll, those products adopted the redesigned information architecture rather than creating their own Settings structure. Each product had a dedicated place within the platform, allowing Settings to grow intentionally instead of becoming increasingly fragmented.
Customer Success embraced the redesign because it directly addressed the challenges they encountered during onboarding. By introducing decisions in a more natural order, removing unnecessary configuration, and standardizing patterns across Settings, the redesign made it easier for Customer Success to onboard new communities and easier for customers to configure the platform with confidence.
The project also established a framework for future design decisions. Rather than finding space for new features on existing pages, future Settings work was expected to fit within the established workflow, reduce unnecessary decisions, and build on existing design patterns. The redesign became a foundation the product team could continue building on as Veras expanded.
