In an era where we can build faster than ever, reducing risk up front is more important than ever. In regulated industries, building products carries extra risk. External compliance and security requirements, complex tech requirements, confusing jargon, and large teams can result in missed deadlines, expensive fixes, or worse, the product might launch and not actually address user needs or meet business goals. These issues all carry risk for the project and the product itself.
Reducing project and product risks with design
At thoughtbot, our designers operate as strategic product partners. We’re flexible, “full-stack” designers who de-risk products before a single line of code is written and continue monitoring risks throughout the process of designing and shipping software.
No matter how experienced a founder or development team is, there will inevitably be unclear requirements, hidden assumptions, and scope creep that can derail projects. We use our years of experience to inform a tailored approach to each project.
What does it look like for thoughtbot designers to reduce project and product risk? Let’s look closer at some common problems we see teams running into.
Misalignment: We don’t know what we are building
We’re firm believers in using design or shaping sprints to align teams, shape the vision of what we’re going to build, and test that vision. As valuable as the artifacts of a sprint are, the shared mental model we establish and the process of identifying risks are arguably more valuable.
Design sprints are sometimes seen as a tool for fast-moving startups, not mature organizations. In practice the opposite tends to be true. The more stakeholders involved, the higher the risk for misalignment. Spending a few days at the start of a project to align on the core problem is a worthwhile investment compared to discovering misalignment three sprints into a build.
In this early stage, thoughtbot designers are not crafting interfaces. We use our design skills to shape ideas and align teams with sketches and flow diagrams that help the entire team understand what we’re planning to build.
We reduce risk by finding the simplest version of an idea that can be validated, meaning we can test that idea by interviewing users. This allows us to quickly answer questions about the core product idea and ensure everyone is aligned.
Incorrect assumptions: Users don’t want what we are building
The people building a product are almost never the people who will use it. This is especially true for regulated industries where you’re building for specialist users such as physicians or finance experts with skills and roles the product team may not fully understand.
Even if the team thinks they are close to the core problem, that proximity can create blind spots. Assumptions about how users think about a problem, what language they use to describe it, and how they expect software to integrate into their workflows tend to get baked into early designs without ever being tested. By the time development is underway, those assumptions become expensive to revisit.
thoughtbot designers work to surface these assumptions as early as possible. During and after a sprint, we build a list of what the team believes to be true about users and test the riskiest ones first. Typically that means interviewing users to ask about their roles and running usability tests to confirm that the language and structure of the design actually matches how users think about the problem. The goal isn’t to eliminate all assumptions, it’s to know which carries the most risk and get answers before the cost of being wrong becomes too high.
Lost time: Developers are waiting on design
While thoughtbot designers are interviewing users, we also identify the parts of the product we are confident about. Low risk features that developers can start building. This ensures the development team can keep moving while the designers dig into riskier areas of the product.
As designers who code, we’re comfortable working alongside developers. We can design the edge cases of a component, figure out responsive layouts, and get the details right, all in code. This means we don’t have to design and document every UI detail in a static design tool like Figma where context can be lost. We’re able to spend more time validating ideas, exploring design solutions, and crafting UI details in the final medium—frontend code.
When it comes to figuring out how specific features should work, thoughtbot designers try to stay 1-2 weeks ahead of development. This gives us a cushion to ensure the development team has a clear list of high priority tasks while also not getting too far ahead of development so the team can pivot the design direction as priorities shift.
Scope creep: New requirements and no time
As time goes on, new information surfaces, requirements shift, and development can take longer than expected. In regulated industries, outside legal or security advisors can bring up unforeseen compliance issues and requirements that need to be accounted for.
thoughtbot designers actively manage scope and ensure we stay agile, even in regulated industries. When new requirements surface, we work with product managers to identify tradeoffs and quickly iterate on designs to show how the change will impact the experience for users.
Design drift: The final product doesn’t look like the design
When the built product starts to diverge from design mockups, that’s usually a symptom of one or more of the problems mentioned above. To avoid this, thoughtbot designers stay close to the code. The static mockups designers create are only a vision of what an experience should look like. We don’t believe it is where every tiny detail needs to be sorted out. Instead we design in the code, writing semantic, scalable HTML and CSS with accessibility baked in.
We pay close attention to accessibility in particular because we value the experience of all users. The rapidly evolving landscape of accessibility requirements in Europe, the United States, and many other places presents a unique challenge for some regulated industries where following accessibility guidelines is not just the right thing to do, it’s the law.
At thoughtbot, we believe constant communication between design and development teams is critical. Without it, teams can’t do their best work and it often results in a lack of trust between departments. Inevitably, context is missed or designs become outdated and everyone gets frustrated. Instead, we work hand in hand with developers to ship polished experiences. This helps build a shared understanding between designers and developers so that the team can work more effectively.
AI shortcuts: We already tried using an LLM for this
AI tools are useful for speeding up parts of the design process. Currently, we use AI tools for generating ideas, synthesizing research, creating prototypes, checking accessibility, and more.
However, it’s not a replacement for a skilled designer who knows how to reduce risk through user testing and validation, align a team with design sprints, and manage competing priorities. That work requires deep context and awareness of tradeoffs. In regulated industries where the wrong solution can result in compliance and security risks, having a skilled designer in the loop is essential. AI makes good designers faster. It doesn’t change what a skilled designer is there to do.
What you should expect from thoughtbot designers
Our goal is to not only launch a successful product but to also leave the teams we work with in a better place. We love to share our expertise, level up client teams, and solve problems you may not have known you had such as defining new design processes, improving accessibility, or starting a design system. We know when to challenge assumptions and bring up potential risks. We help teams quickly “see” the vision and lead them towards a solution that solves user and business needs while actively charting a future roadmap that can be used after the product wraps.
The most expensive design problems in regulated industries often don’t look like design problems. They show up as delayed launches, frustrated compliance teams, and products that cleared every internal review but still didn’t connect with the people they were designed for. Catching those problems before development starts and then continuing to reduce risk throughout the project is what thoughtbot designers do best.