Finding the structure inside the complexity

As Lead Product Designer, I helped shape the product model for Dayforce Studio and bring morestructure to a growing set of capabilities. I worked across product strategy, information architecture,interaction design, and systems thinking.

We started by giving each part of the system a clearer role. Pages were where users created forms,dashboards, documents, and other experiences. Templates made those experiences reusable. Logichandled rules and conditions. Widgets added smaller pieces of functionality. Workflows handledapprovals and multi-step processes. Plugins and Applications supported more specialized use cases.Integrations connected Dayforce to other systems.

Defining the pieces was important, but it was only half the work. The harder part was helping people

Designing the relationships, not just the screens

A user might start with a Page, use a Template, add Logic, trigger a Workflow, and send information toanother system through an Integration. To the employee using it, that should feel like one smoothexperience. To the person building it, those relationships needed to be clear.

That shifted my focus from designing individual screens to designing the system around them.

I worked on ways to help users understand what they had created, what was connected, wheresomething was being used, what depended on it, and what might be affected if they made a change.The goal was to make the invisible structure of an application easier to see without exposing users tounnecessary technical complexity.

Designing for very different users

Studio also had to work for people with very different levels of technical expertise. Administrators andcontent creators needed simplicity. Developers needed flexibility. Employees and managers simplyneeded the final experience to work.

So the experience had to grow with the user. Someone could start with a simple Page, then add moreadvanced capabilities only when the problem required them. That idea of progressive complexitybecame an important part of how I approached the design.

Consistency mattered too. Creating a Page, setting up a Workflow, defining Logic, or configuring anIntegration should not feel like learning a different product every time. I helped establish reusablepatterns around setup, configuration, validation, dependencies, errors, previewing, and publishing.

The outcome

The result was a clearer foundation for Dayforce Studio - one that could support something as simple asa form or as complex as a connected enterprise application without making every user deal with all ofthat complexity at once.

The work helped turn a collection of powerful capabilities into a more coherent building experience:Pages gave users somewhere to start. Templates created reuse. Logic added intelligence. Workflowsmoved business processes forward. Plugins and Applications extended what customers could create.Integrations connected those experiences to the broader enterprise ecosystem.

For me, that was the real design challenge: translating how a complex platform technically works into amodel that makes sense to the person trying to build something with it.