Justworks Engineers are Leveraging Design Thinking
Design Thinking at Justworks
Design thinking is a human-centered approach to innovation, popularized by Stanford’s d.school(opens in a new tab) and IDEO.org(opens in a new tab). Also known as human-centered design, it emphasizes deep empathy and requires practitioners to believe that the people experiencing a problem hold the key to solving it. At Justworks, we believe that solutions are only valuable to the extent that they’re grounded in a true understanding of the problem, and across the organization, we leverage design-thinking principles to drive our understanding of the people we are solving for, the problems they face, and the solutions that fit their needs.
Within Justworks Engineering, some teams have adopted the design thinking mindset, processes, and practices to guide us through cycles of broad exploration and focused convergence. Our teams collaborate across engineering, product, design, sales, finance, legal, operations, customer success, and compliance to reframe problems, question assumptions, and imagine previously unconsidered possibilities. Through rapid prototyping and frequent experimentation, we narrow the solution space and identify outcomes that are desirable, feasible, viable, and rooted in deep knowledge of the user.
Justworks Engineers Apply Design Thinking
At Justworks, our engineers are not only design-thinking participants; we are practitioners, owners, and drivers. Design thinking complements our Agile SDLC, emphasizing the power of process, the value of rapid iteration, and the role of fast failure and bias toward action. Justworks engineers build on the Agile paradigms by centering the human user and working intentionally with experts across disciplines to explore problems and test solutions.As the axiom goes, “Make it work; make it right; make it fast. You’re lucky if you get to the last one.” Justworks takes it a step further - we make sure it solves the right problem!
Case Study
The challenge: the Employer of Record team was modeling the employment lifecycle across three separate, bitemporal data models (role, contract, and employment). Each model captured a slice of the lifecycle, but the fragmentation made it difficult to understand the full picture across the lifecycle timeline. Adding new data fields became labor-intensive and prone to confusion.
Rather than jumping straight into technical fixes, the team approached the problem with a design-thinking mindset. They committed to deeply understanding the employment relationship and lifecycle.
We asked:
What data is essential?
What’s backed by a contract?
What triggers a legal or operational obligation?
What does the employee need to know and when?
What about the employee’s administrator?
Together, we aligned on the key events, requirements, and constraints that shaped the lifecycle.We began with cross-functional workshops that mapped out the entire journey: hiring a new employee, gathering required information, establishing the employment relationship, and reflecting transitions like role and compensation changes, exits, and rehires. The team explored each stage from product, legal, operations, design, and engineering perspectives.
The understanding captured in the workshop scaffolded the engineering team’s work in the next phase of the process. The engineering team started by converging on a shared understanding rooted in our stakeholders experience and expertise. Each engineer sketched their own diagram of the end-to-end lifecycle. Through collaborative review of their individual diagrams, the group created a unified visualization, ensuring a fully aligned mental model.
With clarity around the problem space, the engineering team was ready to move on to explore the full solution space. Design thinking encourages us to diverge before we converge.
With that lens, each engineer independently developed an ideal-state data model that assumed no legacy constraints. Reviewing and synthesizing these ideal state models enabled us to understand our North Star. We then repeated the process, layering constraints back in and asking ourselves how we point to our North Star given our current systems. What’s viable from a maintenance and scalability perspective? What’s sustainable across teams? How can we safely iterate toward our end goal?
The result? A consensus design grounded in the real complexities of our domain, inspired by the clarity of a user- and problem-first mindset.
One engineer led the charge in writing a detailed technical spec and assembled a working group of engineers. Together, they implemented a refactored model of the employment relationship lifecycle, iterating continuously on the original data model design and implementation plan in response to roadblocks and newly discovered constraints. The end result was a single, unified data model that was cleaner, more extensible, and better aligned with the real-world employment relationship lifecycle that it represents.
Design thinking helped us slow down before speeding up, prioritizing deep understanding over fast execution. As engineers, this process reinforced the value of cross-functional collaboration, deliberate divergence, and clear framing before building.





