SaaS - Design Strategy

PROJECT SaaS - Product Design Strategy. This project represents one of the most complex and consequential design undertakings in enterprise software: the full transformation of a legacy, on-premise product suite into a modern, cloud-based Software as a Service platform. It was not a visual refresh or a feature update. It was a ground-up rethinking of how a product should feel, behave, and grow across an organization spanning multiple industries and user types. The work touched every layer of the experience, from the information architecture and interaction patterns down to the foundational design tokens that would power the system at scale. OBJECTIVE The goal was to build a design strategy that would serve as the north star for the entire product transformation. That meant establishing a user-centric foundation built on three pillars: usability, intuitiveness, and visual coherence. The strategy needed to address not just how the product looked, but how it worked for real people with real constraints, whether they were a floor manager checking schedules on a shared tablet or a corporate administrator configuring workflows across dozens of locations. Beyond usability, the strategy had to drive adoption. A product that users resist or work around is a failed product regardless of its technical capabilities. So the design work was intentional about reducing friction at every touchpoint, shortening the learning curve for new users, and building enough consistency into the system that experienced users could move quickly without relearning behaviors from screen to screen. The ultimate measure of success was whether the design helped the business retain users and grow within accounts, not just launch a product. And it did. CHALLENGE The core challenge was not just redesigning a product but dismantling years of accumulated complexity and rebuilding it in a way that felt natural, modern, and scalable. The legacy product suite had been built over many years by multiple teams, each solving problems in isolation. The result was a collection of tools that worked, technically, but that carried inconsistent patterns, redundant flows, and a visual language that reflected a different era of software design. Moving from on-premise to SaaS introduced a new set of expectations. Users accustomed to desktop software expected something that ran with the speed and responsiveness of a modern web product. Enterprise buyers expected the control and configurability of their old tools. And because the platform needed to serve multiple industries simultaneously, the design had to be flexible enough to accommodate very different workflows without feeling generic or bloated. There was also an organizational dimension to the challenge. Aligning cross-functional teams around a shared design vision, especially when different product areas had developed their own conventions, required establishing trust through process and demonstrating early wins to build momentum. PERSONA(S) Managers, full-time employees, and hourly workers Each persona represented a distinctly different relationship with the product, and designing for all three without creating a fragmented experience was one of the central design problems. Managers needed visibility and control. Their primary concern was operational efficiency: being able to configure, monitor, and act quickly without digging through multiple screens or exporting data to make decisions. They needed the product to surface the right information at the right time, and to make complex actions like scheduling, approvals, and reporting feel manageable rather than burdensome. Full-time employees used the product regularly but not always deeply. For them, consistency and predictability mattered most. They needed to trust that the product would behave the same way each time, and that changes or updates would not force them to relearn the tools they depended on daily. Hourly workers often had the least tolerance for complexity and the least time to spend navigating software. Their interactions needed to be fast, direct, and forgiving. Designing for this persona meant eliminating unnecessary steps, prioritizing clarity over comprehensiveness, and ensuring the experience worked well on the devices and conditions they actually used. INDUSTRY Retail, manufacturing, healthcare, HR, and hospitality. Serving five distinct industries with one platform forced a level of design rigor that single-vertical products rarely require. Each industry carries its own operational rhythms, compliance considerations, and cultural norms around software. In retail, speed and simplicity are paramount. Workers operate in high-volume, high-turnover environments where the product needs to work without training overhead. In manufacturing, precision and reliability matter above all else. In healthcare, the stakes of a confusing interface are higher, and the product needs to earn trust immediately. In HR contexts, the platform becomes a system of record, where data integrity and audit trails shape how users interact with it. In hospitality, flexibility is the dominant need, because the work environment changes constantly and the software has to keep up. Rather than building separate experiences for each vertical, the design strategy focused on identifying shared patterns and making them configurable. The goal was a platform that felt native to each context without requiring a separate design system for every industry it served. PROCESS Assessment + Exploration + Research + Prototype + Iterations + Deployment The process was structured to reduce risk while moving quickly through ambiguity. Assessment was about understanding the full scope of what existed. That meant auditing the legacy product, cataloging interaction patterns, identifying inconsistencies, and mapping where users were experiencing the most friction. It also meant aligning with stakeholders on what success looked like before any design work began. Exploration opened up the possibility space. This phase included competitive analysis, design pattern reviews, and early concept work that challenged assumptions about how the product should behave. Not all of it made it forward, but it was essential for building a shared vocabulary across the team. Research grounded the work in reality. User interviews, contextual inquiry sessions, and usability testing with representatives from each persona group shaped the decisions that followed. This was not research as a box to check but as an ongoing practice that continued throughout the project. Prototyping translated strategic decisions into tangible experiences. Low and mid-fidelity prototypes were used to test assumptions early, before the cost of change became high. High-fidelity prototypes came later, once the core interactions had been validated. Iterations refined everything. Each round of testing produced insights that fed back into the design, progressively closing the gap between what the product was and what it needed to be. Deployment was not a handoff but a transition. Close collaboration with engineering during this phase ensured that design intent survived implementation, and that the feedback gathered during rollout informed the next cycle of work. DELIVERABLES Design System, Common Components, Tokens The deliverables from this project were not screen designs. They were infrastructure. The Design System became the shared language for every team building on the platform. It documented not just what components looked like but how they behaved, when to use them, and why certain decisions were made. A well-built design system is like a style guide that also teaches you how to think, and that was the goal here: to give teams the tools to make good design decisions independently, without needing to escalate every question. Common Components were the building blocks of that system. Each component was designed to be flexible enough to serve multiple contexts while remaining consistent enough to reinforce familiarity across the product. They went through multiple rounds of review and testing across the different industry contexts to ensure they held up under real conditions. Tokens were the connective tissue. Design tokens defined the core visual values, colors, spacing, typography, elevation, and motion, in a way that could be consumed by both design tools and front-end code. This meant that changes to the visual language could propagate across the entire product systematically rather than requiring manual updates in dozens of places. It also made the system extensible, allowing teams to introduce new themes or brand variations without breaking the underlying structure. TEAM UX + UI + Research + PM The team was built to cover the full spectrum of the design process, from discovery through delivery. UX designers led the structural and interaction work, ensuring the product made sense from the user's point of view before visual decisions were made. UI designers translated those structures into polished, consistent interfaces that aligned with the evolving design system. Research kept the team honest, ensuring that decisions were grounded in evidence rather than assumption. Product management connected design decisions to business outcomes and kept the work moving through organizational complexity. Collaboration across these functions was not incidental. It was built into the process. Regular critiques, shared documentation, and cross-functional working sessions meant that decisions were made with the full picture in view rather than in silos that had to be reconciled later. ROLE Design leadership and execution. The role spanned both the strategic and the hands-on. At the strategic level, this meant defining the design vision for the transformation, establishing the principles that would guide decision-making across the team, and creating the conditions for consistent, high-quality work at scale. That included building the design system architecture, setting standards for documentation and component governance, and working closely with product and engineering leadership to ensure design had a seat at the table when critical decisions were being made. At the execution level, this meant staying close to the work. Contributing directly to key flows, leading design reviews, and maintaining the quality bar across a large and complex product surface. The goal was not just to direct but to demonstrate, to show what good looked like and help the team get there consistently. The combination of leadership and hands-on execution was essential in a project of this scale. Strategy without execution drifts. Execution without strategy fragments. Holding both together was what made it possible to deliver a coherent, scalable product experience across five industries and three distinct user types.