In good times and bad, healthcare is deeply ingrained in our lives. From the beginning to the end, our providers monitor our growth, treat our illnesses and injuries, and keep us as healthy as possible.

But healthcare organizations can no longer take that provider-patient dynamic for granted. In the wake of the COVID-19 pandemic, more patients than ever distrust the healthcare system. The healthcare industry is also working to recover from the $206.2 billion hit it took in 2020, driven largely by forced delays in preventative care and elective surgeries.

As the healthcare sector finds its footing post-COVID, providers have a tremendous opportunity to build stronger patient relationships than ever before. In 2022, 83% of healthcare consumers said they wanted to make their health and wellness a priority again, while another 37% said they wanted to be more engaged with their healthcare. So where should providers start? With a laser focus on user experience (UX).

As telehealth and retail disrupters like CVS and Amazon gain momentum, it’s easier than ever for patients to get a flu shot or a test for strep throat – a convenience that patients love. These healthcare disruptors also have a leg up in the virtual world, since they’re powered by the modern digital platforms that patients have come to expect.

To find a way forward, traditional healthcare organizations need to focus on creating a strong UX and digital presence that can both compete with disruptors and satisfy the regulatory requirements unique to healthcare (we’re looking at you, HIPAA).

Why Your Patients Expect Better UX

Once upon a time, patients believed that doctors knew best. They went to the healthcare provider down the street and trusted that the provider had the expertise to resolve their health woes.

In 2023, patients are informed consumers. 60% of patients research online before choosing a provider, many of whom consult the healthcare organization’s website. If this isn’t reason enough to revamp your digital footprint, 40% of patients also say they prefer to book appointments online.

Together, these statistics illustrate a growing demand among patients for more robust, patient-friendly digital experiences. The issue is that this is exactly what healthcare organizations have struggled to do for years. At Oomph, some of the most common challenges we see among healthcare brands include:

Yet there are exciting examples of innovation across the industry, too. Forward-thinkers like the Cleveland Clinic are proof that healthcare UX can and should be innovative — largely because better digital capabilities enhance the patient experience, fueling stronger relationships that benefit providers and the patients they serve.

Our healthcare team at Oomph works with providers of all sizes to uncover digital solutions that make sense for their size and structure, budget, and patient needs. Here, Oomph UI Designer Alyssa Varsanyi shares best practices they’ve developed in partnership with our healthcare clients.

Our 4 Healthcare UX Best Practices

1. Be Accessible and Inclusive

Accessibility is non-negotiable for any digital experience. It’s even more important for provider sites, which are likely serving people with a wide range of conditions — all of whom need and deserve complete and immediate access to healthcare.

To create a healthcare UX accessible to all, healthcare organizations should:

2. Create a Safe Space

In healthcare, protecting patient data is table stakes. To create a safe space, you have to think not just about patient confidentiality but also about building trust. A thoughtful digital environment with inclusive language can go a long way to helping patients feel seen, heard, and cared for.

Websites like Cedars-Sinai are a great example of how websites can be built around trust. Their platform exemplifies how language can be the foundation for a credible site, especially when paired with supportive modules like sources and testimonials.

To take the same approach to your site:

3. Make Navigation Easy

Many patients come to healthcare systems with an immediate need — a parent needs to find an open appointment NOW for their child’s pre-season sports physical, or a cooking enthusiast needs to locate an urgent care on a Sunday to patch up the new chopping-related cut on their hand.

In either scenario — and countless others that people face daily — it’s critical that patients can easily find the right information at the right time and in the right way.

To make this a reality, healthcare organizations should strive to:

As technical as these tactics are, don’t forget to show empathy, too. It is possible to show compassion online, like how Stanford Health poses the question, “What can we help you find?” Emotional asks like this can illustrate an organization’s genuine desire to be helpful to their patients.

4. Build Responsive Experiences

Healthcare needs don’t wait until patients are sitting in front of their computers. Think about an adult child peeking over their senior parent’s shoulder while they search for a specialist, or a new parent scrolling through their phone at midnight while cradling their sick baby.

Now imagine those people frantically pinching at the screen so they can read the entire text block or find the right button. Stressful, right?

Patients should be able to seamlessly access healthcare anytime anywhere, which means designs must be responsive. Keep in mind:

What does that look like in practice? Consider the Summit Health website. Its simple navigation makes it easy for patients to find what they’re looking for, while the responsive design enables patients to engage on the go.

Healthcare UX Is a Journey, Not a Destination

At Oomph, we’ve seen firsthand how these healthcare UX best practices transformed the patient experience of our many healthcare clients. Even still, it’s important to note that UX isn’t one-size-fits-all. A national network of hospitals may need a very different digital patient experience than an owner-operated group of general practice clinics.

So how do you start building a UX that works for you and your patients? Research and testing.

UX audits, user research, and usability testing are all keys to the lock that is an effective UX strategy. By identifying what’s working and what’s not, what your patients want and what they don’t, you can put your organization on an evidence-based path to world-class UX.

Interested in exploring ways to improve UX for your own patients? We’re here to help.


Connecting People and Planet

NEEF’s website is the gateway that connects its audiences to a vast array of learning experiences – but its existing platform was falling short. The organization needed more visually interesting resources and content, but it also knew its legacy Drupal site couldn’t keep up.

NEEF wanted to build a more powerful platform that could seamlessly:


Strategy is the foundation for effective digital experiences and the intuitive designs they require. Oomph first honed in on NEEF’s key goals, then implemented a plan to meet them: leveraging existing features that work, adding critical front- and back-end capabilities, and packaging it all in an engaging, user-centric new website.

Information architecture is at the core of user experience (UX). We focused on organizing NEEF’s information to make it more accessible and appealing to its core audiences: educators, conservationists, nonprofits, and partners. Our designers then transformed that strategy into strategic wireframes and dynamic designs, all of which we developed into a custom Drupal site.

The New NEEF: User-Centered Design

A Custom Site To Fuel Connection

NEEF needed a digital platform as unique as its organization, which is why Oomph ultimately delivered a suite of custom components designed to accommodate a variety of content needs.

Engaging and thoughtful design

NEEF’s new user experience is simple and streamlined. Visual cues aid in wayfinding (all Explore pages follow the same hero structure, for example), while imagery; microinteractions, such as hover effects; and a bold color palette draw the user in. The UX also emphasizes accessibility and inclusivity; the high contrast between the font colors and the background make the website more readable for people with visual impairments, while people with different skin tones can now see themselves represented in NEEF’s new library of 100 custom icons.

Topic-based browsing

From water conservation to climate change, visitors often come to the NEEF site to learn about a specific subject. We overhauled NEEF’s existing site map to include topic-based browsing, with pages that roll resources, storytelling, and NEEF’s impact into one cohesive package. Additional links in the footer also make it easier for specific audiences to find information, such as nonprofits seeking grants or teachers looking for educational materials

NPLD host resources and event locator

Oomph refreshed existing components and added new ones to support one of NEEF’s flagship programs, National Public Lands Day (NPLD). People interested in hosting an event could use the new components to easily set one up, have their own dashboard to manage, and add their event to NEEF’s event locator. Once the event has passed, it’s automatically unlisted from the locator — but archived so hosts can duplicate and relaunch the event in future years.


Protecting the Planet, One User at a Time

Oomph helped NEEF launch its beautiful, engaging, and interactive site in May 2023. Within three months, NEEF’s team had built more than 100 new landing pages using the new component library, furthering its goal to build deeper connections with its audiences.

As NEEF’s digital presence continues to grow, so will its impact — all with the new custom site as its foundation.


Rapid Discovery with a Cohort Analysis

Oomph hit the ground running, bringing our human-centered design expertise and passion for environmental causes to strategize a solution. We knew that balancing rigor and speed would be critical – how could we design a site positioned for success without over-investing in features that might need to change later? Through market and user research, rapid prototyping, and close collaboration with Rare and development partner Adapt, we swiftly moved from vision to reality.

Surveying the Landscape

While purchasing carbon credits is similar to making a nonprofit donation in some ways, it also blends elements of investing and crowdfunding in a distinct experience. Oomph first conducted a cohort analysis of more than 20 platforms, from other emerging carbon credit marketplaces to crowdfunding sites like Kickstarter and Kiva. The process uncovered some promising initial approaches, but also underscored the lack of best practices in the space. Ultimately, we determined that Catch Carbon needed to emphasize real-world impact: giving like-minded supporters a place to rally behind a shared cause and directly see the positive effects of their dollars.

Creating Connection and Credibility with Users

Building on Rare’s insights into its audience – climate-concerned citizens eager to be part of the solution – we knew that Catch Carbon would primarily draw users interested in taking personal action to reduce carbon impacts. User journey mapping allowed us to anticipate the visitor’s thoughts and feelings at every stage – curious as they enter the site, inspired as they browse projects, proud after deciding to purchase – and make design choices to guide them along the way. Our strategy included:

A Collaborative Design Process

With a solid strategy in place, Oomph dove in to bring the design to life. We led Rare through a 20-second design “gut check” workshop to develop a shared design language, then used style tiles to quickly hone in on the design aesthetic. As we moved into full page designs, we worked hand in hand with Adapt and Rare to test an internal API system that would populate project data, refining the design in real time as we determined which information was possible to include.


Just seven weeks after project kickoff, the Catch Carbon site debuted to the public. Its launch marked a major step forward for the voluntary carbon credit market, democratizing access for consumers and setting new standards for project transparency and quality. As a member of 1% for the Planet, Oomph is personally invested in sustaining our world for generations to come – making our work with Rare especially meaningful.

In addition to bringing Rare’s bold new idea to the public quickly, we equipped the organization with a set of KPIs to measure the effectiveness of specific design choices. By understanding factors like site traffic patterns and drop-off rates, Rare can test and iterate with precision.

Climate change is an insurmountable challenge to solve alone, but together, our efforts can make a difference. The Catch Carbon marketplace brings everyday people closer to carbon reduction solutions than ever before, spurring the behavioral change that’s at the heart of Rare’s mission.

In our previous post we broadly discussed the mindset of composable business. While “composable” can be a long term company-wide strategy for the future, companies shouldn’t overlook smaller-scale opportunities that exist at every level to introduce more flexibility, longevity, and reduce costs of technology investments.

For maximum ROI, think big, then start small

Many organizations are daunted by the concept of shifting a legacy application or monolith to a microservices architecture. This is exacerbated when an application is nearing end of life.

Don’t discount the fact that a move to a microservices architecture can be done progressively over time, unlike the replatform of a monolith which is a huge investment in both time and money that may not be realized for years until the new application is ready to deploy.

A progressive approach allows organizations to:

Prioritizing the approach by aligning technical architecture with business objectives

As with any application development initiative, aligning business objectives with technology decisions is essential. Unlike replatforming a monolith, however, prioritizing and planning the order of development and deployments is crucial to the success of the initiative.

Start with clearly defining your application with a requirements and feature matrix. Then evaluate each using three lenses to see priorities begin to emerge:

  1. With a current state lens, evaluate each item. Is it broken? Is it costly to maintain? Is it leveraged by multiple business units or external applications?
  2. Then with a future state lens, evaluate each item. Could it be significantly improved? Could it be leveraged by other business units? Could it be leveraged outside the organization (partners, etc…)? Could it be leveraged in other applications, devices, or locations?
  3. Lastly, evaluate the emerging priority items with a cost and effort lense. What is the level of effort to develop the feature as a service? What is the likely duration of the effort?

Key considerations when planning a progressive approach

Planning is critical to any successful application development initiative, and architecting a microservices based architecture is no different. Be sure to consider the following key items as part of your planning exercises:

  1. Remember that rearchitecting a monolith feature as a service can open the door to new opportunities and new ways of thinking. It is helpful to ask “If this feature was a stand alone service, we could __
  2. Be careful of designing services that are too big in scope. Work diligently to break down the application into the smallest possible parts, even if it is later determined that some should be grouped together
  3. Keep security front of mind. Where a monolith may have allowed for a straightforward security management policy with everything under one roof, a services architecture provides the opportunity for a more customized security policy, and the need to define how separate services are allowed to communicate with each other and the outside world

In summary

A microservices architecture is an approach that can help organizations move faster, be more flexible and agile, and reduce costs on development and maintenance of software applications. By taking a progressive approach when architecting a monolith application, businesses can move quickly, reduce risk, improve quality, and reduce costs.

If you’re interested in introducing composability to your organization, we’d love to help! Contact us today to talk about your options.

“Inclusive design” may sound like vague, trendy, technical jargon. But inclusive design isn’t a trend — it’s the world catching up on the kind of digital experiences that should have been part of the web from the beginning.

Inclusive design is a crucial part of nearly every digital platform, be it website, app, or intranet.

Inclusive design as a concept and practice is broad and deep — this article barely scratches the surface, but will help you understand the mindset required. We’ll cover what it is, why it matters for your business, and some ways to assess whether your digital platform could be more inclusive.

  1. What does “inclusive design” mean?
  2. What are the benefits of inclusive design?
  3. How are inclusive design and accessibility different?
  4. How can you make your platform more inclusive?

What does “inclusive design” mean?

The Inclusive Design Research Center defines inclusive design as “design that considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.” Adding to that, Nielsen Norman calls it creating products that “understand and enable people of all backgrounds and abilities,” including economic situation, geography, race, and more.

Essentially, you’re aspiring to create interfaces that reflect how people from all walks of life interact with the world.

Inclusive design allows people to use a digital platform with ease, whatever their needs or point of view. Looking at characteristics like race, abilities, or geography helps us identify key areas where friction can occur between humans and the web.

In the end, it’s about designing for everyone.

What are the benefits of inclusive design?

Inclusive design isn’t just about recognizing and accommodating diversity; it also creates business advantages for organizations that are willing to invest in an inclusive approach. Here are a few key areas where inclusive design can give your digital platform an edge:

Grow your customer base. By understanding the best way to connect with a wider target audience, your team can create digital experiences that attract the most possible users.

Increase user engagement. Engagement goes up when platforms are welcoming and easy to use. Inclusive web design removes barriers and creates motivation for people to engage with your brand.

Spark innovation. Inclusive solutions have a history of spawning innovation that goes beyond the initial intended audience (think closed-captioning-turned-subtitles on Netflix). Sometimes, when you aim to solve a specific usability issue, you end up creating an entirely new market solution.

Motivate your team. The way a digital platform is designed affects all audiences, even employees. Designing with inclusivity in mind can also have a positive influence on your own team. Engaging employees in your efforts to build an inclusive digital platform can help create a sense of shared purpose — one many people are likely to rally around.

How are inclusive design and accessibility different?

You may have heard these terms used in similar contexts. While they overlap in meaning, they’re not the same thing.

By definition, accessibility focuses on accommodating people with varying physical and mental abilities. Accessible websites are measured by their conformance with Web Content Accessibility Guidelines, which pertain to things like auditory, cognitive, physical, and visual disabilities. Accessibility tests typically cover code-level issues that can be fixed in the source code of a site.

Inclusive design is about accommodating the entire spectrum of human diversity. It involves a variety of viewpoints, including those of people with disabilities. Inclusive solutions can involve anything from back-end coding to the way headlines are worded.

In a nutshell: An accessible site is one of the outcomes of an inclusive design, whereas inclusive design is the overall approach to creating accessibility.

Consider these examples:

Sample non-inclusive form presents the statement I identify my ethnicity as, with three choices of Black or African, Caucasian or White, and Hispanic or Latino
Note: This is a terrible example of inclusion. People who identify as biracial, Asian, Middle Eastern, or Native American (just to name a few) need to choose from experiences that do not match their own. Simple user research can uncover a variety of choices that would make this form more inclusive.

While both issues are addressed by inclusive design, the first issue relates to ability and can be fixed within the code, while the second relates to diversity and will take additional measures to address.

How Can You Make Your Platform More Inclusive?

The ethnicity example raises some interesting questions, such as:

Mainly, this raises a bigger question: how do you maintain an inclusive site when there are so many important and broad variables (ability, language, culture, gender, age, etc.) — especially when that list of variables continues to grow and change?

The best way to get started is to arm yourself with knowledge and create a plan.

1. Identify the problems to solve.

Start by identifying opportunities for improvement in your current user experience (UX) by collecting quantitative and qualitative research with tools like UX audits, user interviews, user recordings, and heatmaps. Keep an eye out for areas where users seem confused, backpedal, or struggle to complete tasks. The more information you gather, the better!

2. Determine the best solutions.

Your user research will likely uncover many possible paths to change. This may include adding more categories to a list, creating an “Other” field users can type any answer into, or adding options to gather additional information.

Note: It’s common for areas that need improvement to hit on sensitive topics, things you may not fully figure out through data and research. Remember that the goal is understanding. Don’t be afraid to reach out to others for their thoughts and opinions.

3. Measure the results.

Some measures of success are easy to determine from user data in Google Analytics or changes in heatmaps and user recordings. Further data can come from users via surveys asking how your audience feels about the changes. The key is to stay continuously informed and aware of what your users are experiencing.

Note: One helpful tool for checking whether your design is, in fact, inclusive is Cards for Humanity. It offers a fun way to make sure you’re not missing anyone or anything in the spectrum of inclusivity.

Remember that the process of creating an inclusive design doesn’t end with implementation. Inclusive design is a work in progress. As a field, inclusive design is always evolving and requires continuous research to develop best practices.

We can’t predict what kind of mismatched interactions users will face in the years to come. But, with an open mind and a desire to learn and grow, we can continually adapt to meet them.

We’ve only scratched the surface of inclusive design! If you have any questions about inclusive design, we’d love to chat. Contact us anytime.


AskRI is a digital platform providing Rhode Island residents with free access to some of the top educational and research tools, along with links to many state resources. A collaboration among the state government and various libraries and agencies, AskRI is essentially a 24/7 help desk for Rhode Islanders.

The platform’s structure has three main approaches:


Online portals provide free access to premium third-party tools and services, including research platforms and libraries, online learning and tutoring platforms, and consumer resources for health, jobs, and more.


AskRI curates information and resources for specific audiences, including K-12 students and teachers, parents, non-native-English speakers, and adults seeking continuing education.


Supporting local librarians with ready-made links, the FAQ section answers crowd-sourced questions about a variety of government services (how to get a green card, where to get a fishing permit, etc…).

Fundamentally, it’s an incredible resource! But, as AskRI grew over time, it became increasingly difficult for users to find the information they needed — and harder for site managers to organize, update, and expand the content.

Aiming to make the platform more user-friendly all around, its owners opted for a comprehensive redesign with a few primary goals:


Through a quick Discovery phase, we uncovered a diverse user base with a broad range of needs. Our next challenge was to create an energetic brand identity and a more intuitive way to organize the platform.

Visual Branding

Rhode Island is a small but unique place, and its residents are proud of their state. We wanted the new branding to leverage a more modern, yet uniquely Rhode Island, identity. It could also evoke a sense of engagement, reinforcing the platform’s two-way interaction.

Over several design rounds, we explored logos that would represent two-way conversations while suggesting Rhode Island’s distinct shape. We also introduced a new, brighter color palette.

Digital Platform

Redesigning the platform came down to an exercise in information architecture: What was the best way to organize the content so users could quickly find the tools and resources that were most relevant to them?

We knew only a small segment of the target audience would know exactly what they were looking for and be able to search for it directly. Most users would be on a mission of discovery, needing a way to browse the content. Then there was the FAQ section, where users might expect to find answers about the platform itself — but in its current form, the FAQs were confusingly broad and hard to find.

Our solution addressed all three areas:

  • Knowing that frequent users would want to get to familiar databases quickly, we incorporated tried-and-true search and filter tools
  • For those needing more guidance, we created a persona-based architecture with curated lists of content that addressed each persona’s unique needs
  • By making the platform simpler and more intuitive, we removed the need for an FAQ section. We replaced it instead with a more interactive feature


These relatively simple changes brought powerful results, creating a more engaging and intuitive platform. The fresh branding celebrates inquisitiveness and interaction, while the redesigned content is much easier for users to navigate and for authors to organize and expand.

The AskRI team loved the new brand identity, which evokes curiosity with visual elements that represent thinking and asking questions. Two thought bubbles form the shape of Rhode Island for the logo, while images of inquisitive people are featured throughout the site. In addition, the new colors bring fresh energy to the brand while preserving a sense of trust and authority.

The redesign not only improved the content’s organization and accessibility, it also fosters a greater sense of interaction with platform users. Visual personas provide an intuitive starting point for exploration, backed up with curated resource lists. A new dropdown menu titled “Find Resources for You” speaks directly to target audiences, while a new “Explore Topics” section offers lists of state resources grouped by user needs (small business, health, families, etc.).

Finally, as the most interactive part of the platform, the redesigned FAQs section is now the “Ask a Librarian” page, where users can submit questions on any topic. The most common platform-related questions get published to the site as a list of answers that users can browse. Input from users will not only inform the kinds of content that goes on the site, but may also spur access to new tools and databases.


While One Percent for America (OPA) had an admirable goal of helping eligible immigrants become U.S. citizens, the project faced a major stumbling block. Many immigrants had already been misled by various lending institutions, payday loans, or high-interest credit cards. As a result, the OPA platform would need a sense of trustworthiness and authority to shine through.

The platform also had to handle a broad array of tasks through a complex set of workflows, backstops, and software integrations. These tasks included delivering content, signing up users, verifying eligibility, connecting to financial institutions, managing loan data and investment balances, and electronically sending funds to U.S. Citizenship and Immigration Services.


Given the challenges, our work began with a month-long discovery process, probing deeper into the audience, competitive landscape, customer journeys, and technological requirements for the platform. Here’s what we learned.

The Borrower Experience

Among those deep in the citizenship process and close to finishing the paperwork, many are simply waiting to have the funds to conclude their journey. For them, we designed as simple a workflow as possible to create an account, pass a security check, and apply for a loan.

Other users who are just starting the process need to understand whether they’re eligible for citizenship and what the process entails. We knew this would require smart, in-depth content to answer their questions and provide guidance — which was also a crucial component in earning their trust. Giving away genuinely helpful information, combined with carefully chosen language and photography, helped lend authenticity to OPA’s stated mission.

The Investor Experience

OPA sought to crowdfund capital from small investors, not institutions, creating a community-led funding source that could scale to meet borrowers’ needs. A key innovation is that funders can choose between two options: making tax-deductible donations or short-term loans.

If an investor makes a loan, at the end of the term they can decide to reinvest for another term, turn the money into a donation, or withdraw the funds. To reinforce the circular nature of the platform, we designed the experience so that borrowers could become investors themselves. The platform makes it easy for borrowers to change their intent and access different tools. Maturity dates are prominently displayed alongside “Lend Again” and “Donate” actions. Testimonials from borrowers on the dashboard reinforce the kinds of people who are helped by an investment.

The Mobile Experience

Our research made it clear the mobile experience had to be best in class, as many users would either prefer using a phone or didn’t have regular access to a tablet or computer. But, that didn’t mean creating a mobile app in addition to a desktop website. Instead, by designing a universal web app, we built a more robust experience — more powerful than most mobile apps — that can be used anywhere, on any device.

However, tasks like signing up for an account or applying for a loan need to be as easy on a mobile device as on a desktop. Key UX elements like step-by-step workflows, large touch targets, generous spacing on form fields, soft colors, and easy-to-read fonts produced a highly user-friendly interface.


Together with our technology partners, CraftsmanMotionpoint, and, we built an innovative digital platform that meets its users exactly where they are, from both a technological and cultural standpoint.

This groundbreaking work earned us a Gold Medal from the inaugural 2022 Anthem Awards, in the Innovation in Human and Civil Rights category. The award recognizes new techniques and services that advance communities and boost contributory funds.

In our ongoing partnership with OPA, Oomph will continue working to expand the business model with new features. We’re proud to have helped build this impactful resource to support the community of new Americans.

From code to launch

4.5 mos.

Sites launched within a year


Performance improvement

350 %


A Fractured System

With a network of websites mired in old, outdated platforms, Rhode Island was already struggling to serve the communication needs of government agencies and their constituents. And then the pandemic hit.

COVID accelerated the demand for better, faster communication and greater efficiency amid the rapidly changing pandemic. It also spotlighted an opportunity to create a new centralized information hub. What the government needed was a single, cohesive design system that would allow departments to quickly publish and manage their own content, leverage a common and accessible design language, and use a central notification system to push shared content across multiple sites.

With timely, coordinated news and notifications plus a visually unified set of websites, a new design system could turn the state’s fragmented digital network into a trusted resource, especially in a time of crisis.


Custom Tools Leveraging Site Factory

A key goal was being able to quickly provision sites to new or existing agencies. Using Drupal 9 and Acquia’s Site Factory, we gave the state the ability to stand up a new site in just minutes. Batch commands create the site and add it to necessary syndication services; authors can then log in and start creating their own content.

We also created a set of custom tools for the state agencies, to facilitate content migration and distribution. An asynchronous hub-and-spoke syndication system allows sites to share content in a hierarchical manner (from parent to child sites), while a migration helper scrapes existing sites to ensure content is properly migrated from a database source.

Introducing Quahog: A Design System

For organizations needing agility and efficiency, composable technology makes it easier to quickly adapt digital platforms as needs and conditions change. We focused on building a comprehensive, component-based visual design system using a strategy of common typography, predefined color themes and built-in user preferences to reinforce accessibility and inclusivity.

The Purpose of the Design System

The new, bespoke design system had to support four key factors: accessibility, user preferences, variation within a family of themes, and speedy performance.

Multiple color themes

Site authors choose from five color themes, each supporting light and dark mode viewing. Every theme was rigorously tested to conform with WCAG AA (and sometimes AAA), with each theme based on a palette of 27 colors (including grays) and 12 transparent colors.

User preferences

Site visitors can toggle between light or dark mode or use their own system preference, along with adjusting font sizes, line height, word spacing, and default language.

Mobile first

Knowing that many site visitors will be on mobile devices, each design component treats the mobile experience as a first-class counterpart to desktop.

Examples: The section menu sticks to the left side of the viewport for easy access within sections; Downloads are clearly labelled with file type and human-readable file sizes in case someone has an unreliable network connection; galleries appear on mobile with any text labels stacked underneath and support swipe gestures, while the desktop version layers text over images and supports keyboard navigation.

High Accessibility

Every design pattern is accessible for screen readers and mobile devices. Color contrast, keyboard navigation, semantic labelling, and alt text enforcement all contribute to a highly accessible site. Extra labels and help text have been added to add context to actions, while also following best practices for use of ARIA attributes.

Performance aware

Each page is given a performance budget, so design components are built as lightly as possible, using the least amount of code and relying on the smallest visual asset file sizes possible.


Efficient and Effective Paths to Communication

The first sites to launch on the new system, including, went live four and a half months after the first line of code was written. A total of 15 new sites were launched within just 8 months, all showing a 3-4x improvement in speed and performance compared with previous versions.

Every site now meets accessibility guidelines when authors adhere to training and best practices, with Lighthouse accessibility and best practice scores consistently above 95%. This means the content is available to a larger, more diverse audience. In addition, a WAF/CDN provider increases content delivery speeds and prevents downtime or slowdowns due to attacks or event-driven traffic spikes.

State agencies have been universally pleased with the new system, especially because it provides authors with an improved framework for content creation. By working with a finite set of tested design patterns, authors can visualize, preview, and deploy timely and consistent content more efficiently and effectively.

We were always impressed with the Oomph team’s breadth of technical knowledge and welcomed their UX expertise, however, what stood out the most to me was the great synergy that our team developed. All team members were committed to a common goal to create an exceptional, citizen-centered resource that would go above and beyond the technical and design expectations of both agencies and residents alike.

ETSS Web Services Manager, State of Rhode Island

Our team recently worked through the first phase of a large government platform run by a component design system. The goals were to create a set of visual themes that could support accessibility, native light- and dark-mode switching, and a set of content components that were flexible enough to support more than 70 government agencies. There is quite a bit of complexity to the system, but what we’d like to focus on right now is how we are managing the color system.

The sites are still evolving, but the current count is five color themes, each with a light- and dark-mode, using a total of 46 colors. We decided to use PatternLab to manage our design patterns, which means that each component is comprised of its own Sass, JS, and Twig files packaged together in a portable way. It also means that we could leverage custom Gulp processes to make some pretty cool stuff happen.

First, our goals of using PatternLab and creating a single source of truth:

For the government employee using this system, our goals were to:

And for the end-user viewing any of these sites, we wanted to support:

Here’s how we were able to achieve those goals.

One (H)JSON file to rule them all

We decided that our single source of truth needed to be in a flexible and simple format. JSON fit our needs the best with its ability to support nested relationships and arrays. The only thing it didn’t allow was comments, which can add legibility and documentation. We found that HJSON was a great compromise, and used Gulp to convert our master HJSON file to JSON as part of the build process1.

The HJSON file is one large array. Colors are defined one level deep alongside themes, which are also one level deep. The first level of the structure looks like this:

  "colors": { … }
  "themes": [ … }


Color Definitions

Simple so far. Inside the colors array, individual definitions are structured as a single-depth array:

    # Medium blue
    "ocean--dark": {
      "name": "Ocean State dark",
      "hue": "medium blue",
      "hsl": "hsl(208, 12%, 32%)",
      "needs": "light-text"
    "ocean": {
      "name": "Ocean State",
      "hue": "medium blue",
      "hsl": "hsl(208, 54%, 73%)",
      "needs": "dark-text"
    "ocean--light": {
      "name": "Ocean State light",
      "hue": "light blue",
      "hsl": "hsl(208, 58%, 92%)",
      "needs": "dark-text"
    "ocean--trans25": {
      "name": "Ocean State 25% transparent",
      "hue": "medium blue",
      "hsl": "hsla(208, 54%, 73%, 0.25)",
      "needs": "dark-text"


There are 46 colors total, but they all follow this pattern2. The first key is the name of the color, written in a slug form that will work in Sass and Twig. We like BEM, so the naming of our colors follow a similar idea. We tried to keep naming things easy, so once a color name is established, its variations are “–darker”, “–dark”, “–light”, with some colors using variations like “–bright” or “–trans25”.

Within each color definitions are the following bits of data:

Outside of Pattern Lab, the colors in our system are represented by this preview from our documentation:

A grid of colors swatches where proximity denotes how they are related on the color wheel
The color system as envisioned during the design and theme exploration phase

Turning HJSON Colors into Sass

Now the fun begins.

With our custom Gulp process, these HJSON definitions get turned into minified JSON. This happens as part of the initial build time. Once that JSON is created, when our Sass is saved and a new compilation happens, the contents of that JSON file are available to the Sass build process as a large Sass array. That allows a Sass file to define all of these colors as custom properties:

In a file called _colors.scss, we use an @each loop to write them all into our stylesheet as CSS custom properties on the HTML element3:

html {
  /* Default color CSS vars */
  @each $key, $value in $colors {
    --c__#{$key}: #{map-get($value, hsl)};

Sass (Scss)

The output looks as you might expect. The Gulp process converts the colors from the HSL color space into the more typical Hexidecimal and RGBA color spaces:

html {
  --c__ocean--dark: #48525b;
  --c__ocean: #95bddf;
  --c__ocean--light: #dfebf6;
  --c__ocean--trans25: rgba(149, 189, 223, 0.25);


Turning HJSON Colors into Twig

That’s pretty cool, but it gets cooler. In a design system tool like Pattern Lab, we want to display swatches of these colors to end users of the design system. This is where the same ideas as converting JSON to Sass can be applied inside Twig files. The JSON file is read into and available as an array as well, which allows a colors.twig file to do this:

<ul class="sg-colors">
  {% for key, color in colors %}
      <span class="sg-swatch" style="background: {{ color.hsl }};"></span>
      <span class="sg-label"><b>{{ }}:</b> {{ color.hsl }}</span>
      <span class="sg-code"><code>var(--c__{{ key }})</code></span>
  {% endfor %}


for loop in Twig iterates on the array and outputs a color swatch, a human-readable label, and the name of the CSS custom property. Pretty neat! Now we can update our colors in the HJSON file and those changes trickle down to the Sass definition and the Twig preview as well as our CSS stylesheet.

A grid of color swatches produced by the Pattern Lab design system documentation tool
A preview of all colors defined in the Pattern Lab design system

But that’s not all…

Theme Definitions

The second array in our HJSON file controls our themes — again, five different color themes each with a light- and dark-mode. To manage these effectively, we had to make some architectural decisions. Here is where we landed:

This structure allows a front-end developer to only concern themselves with the functional color name — i.e., --fc__nav-main__link. They don’t need to know what color that maps to as long as it has been defined in the theme. The theme designer is the one that focuses on making colors available and controlling the accessibility of those color combinations.

Define the Themes

Much like our color definitions, the top depth of the array defines our color theme

"palettes": {
  "scarborough": {
      "humanName": "Scarborough Beach",
      "values": { … }


We only need a slug, which is the array key, and a humanName. The slug will be used to output a list of colors per theme. The human-readable name is used in a dynamically-generated list of available themes through the authoring admin screens (more to come on that later).

Define the Components

Inside the values array, each component definition is included. The list is long, but a sample of it looks like this (with our inline comments allowed by HJSON):

"header": [
  { "fnName": "fg", "colorName": "white" },
  { "fnName": "bg", "colorName": "navy" },
  { "fnName": "link", "colorName": "white" },
  { "fnName": "link--hover", "colorName": "ocean" },
  { "fnName": "social__link", "colorName": "ocean" },
  # Hover should be the same as the default accent color
  { "fnName": "social__link--hover", "colorName": "hope-gold" }


These compile to a list of color definitions per component. The final color variables look like this:

html {
  /* Default functional colors used by the header component */
  --fc__header__fg: white;
  --fc__header__bg: #293557;
  --fc__header__link: white;
  --fc__header__link--hover: #95bddf;
  --fc__header__social__link: #95bddf;
  --fc__header__social__link--hover: #face3d;


Output the theme components

Our themes are controlled by overriding the functional color definitions with specificity. A loop in our colors.scss file renders all the colors and all the themes as CSS variables. The first theme definition serves as our default, while additional definitions with a class present on the <body> override those definitions.

It makes more sense in CSS. Here is a full example of only the header component:

html {
  /* Default functional colors used by the header component */
  --fc__header__fg: white;
  --fc__header__bg: #293557;
  --fc__header__link: white;
  --fc__header__link--hover: #95bddf;
  --fc__header__social__link: #95bddf;
  --fc__header__social__link--hover: #face3d;
/* Default colors for dark mode (overrides only) */
html.dark {
  --fc__header__bg: #1b243b;
@media (prefers-color-scheme: dark) {
  html:not(.light) {
    --fc__header__bg: #1b243b;
/* Component colors when a theme class is present (overrides only) */
html .qh__t__federal-hill {
    --fc__header__bg: #8e3339;
    --fc__header__link--hover: #face3d;
    --fc__header__social__link: white;
/* Component colors when a theme class is present AND it is dark mode (overrides only) */
html.dark .qh__t__federal-hill {
    --fc__header__bg: rgba(235, 82, 82, 0.15);
    --fc__header__social__link: #eb5252;
@media (prefers-color-scheme: dark) {
  html:not(.light) .qh__t__federal-hill {
      --fc__header__bg: rgba(235, 82, 82, 0.15);
      --fc__header__social__link: #eb5252;


The power of CSS specificity helps us here. The top of the file is our fallback for any functional color in our default theme — they all need to be present here. Any additional definitions only need to change those colors. Anything in html.dark overrides the colors in html4. Anything in html .qh__t__federal-hill overrides colors in html with specific theme colors. And anything in html.dark .qh__t__federal-hill overrides colors in html .qh__t__federal-hill when dark mode is present.

Outputting Visual Theme Previews

Similar to the Twig for loop for color swatches, we created a loop in Pattern Lab that renders a visual swatch to represent a theme. I won’t go into all the code here, but the trick we used was to create stripes of color using an inline CSS linear-gradient(). The result looks like this:

A grid of large color swatches consisting of striped of color produced by the Pattern Lab design system documentation tool
A preview of all color theme palettes defined in the Pattern Lab design system

Taking it a Step Further for Accessibility

We decided that the theme designer would be responsible for providing accessible color contrast ratios (CCR) when defining --bg and --fg colors. It is up to them to choose which combinations to use, but with 46 colors, that’s 2,116 possible combinations! How can a theme designer know which combinations pass which CCRs?

Through the power of programming, we created another Twig file that leverages a nested for loop to create a large table. Across the top are our 46 colors and down the side are our 46 colors again. In the middle where a color row intersects a color column, we render enough data on the table cell to allow a Javascript loop to calculate the CCR for that combination of colors.

The result is a data table that shows every color combination and how that combination passes or does not conform to WCAG CCR thresholds. The power of for loops!

Here is what that looks like:

A grid of small color swatches that represents combination of colors and the calculated color contrast ratios of those combinations
A preview of all 2,116 possible color combinations and their calculated CCRs

A fun little thing here is that we used emojis as our visual output. Anything under 3.0 is not allowed, anything 3.0 to 4.5 is passable under certain conditions, while anything over 4.5 is great and anything over 7.0 is royalty.

function setMessage(ccr) {
  var message = '';
  if (ccr >= 7.0) {
    messge = '👑';
  if (ccr >= 4.5) {
    message = message + '✅';
  if (ccr < 4.5 && ccr >= 3.0) {
    message = '🟡';
  if (ccr < 3.0) {
    message = '🚫';
  return message;


Another trick here was how to calculate CCR when one or more of the colors are transparent. In short, we had to do some JS that was aware of the background color — therefore, view this table in light mode AND dark mode to get the fullest amount of data around transparent color combinations.

Displaying a Theme Selection

The final step of making our HJSON file control colors and themes from end to end is getting the list of themes into the admin of the site. With this, a site author can choose a color theme for their site, and further, when we add a new theme, that setting is available as soon as there is a new design system deployment.

A bit of PHP in the Drupal theme-settings.php file cycles through our JSON to render the select list of theme names. The end result of that looks like this:

A select list of theme options in our CMS of choice

Wrapping it all Up

In an extreme example of the DRY principle (Don’t Repeat Yourself), we’ve set up a system where one file rules all of our color definitions. A JSON array can render the following data through a Gulp process:

A HJSON to JSON/Sass/Twig/PHP workflow is certainly a great foundation. While this file manages only colors and themes, the same workflow could manage font-families, font-sizes, spacing values, and more. For now, we are taking it one step at a time but this certainly gives us some ideas to expand upon in the future.

  1. Yes, we could have added a comment field to our JSON structure, but we wanted more than that. Commenting individual lines with a hash character (“#”) was very helpful when we got to defining entire color themes 
  2. Is this article actually about the new hotness, “design tokens”? Yes, in some ways, it is. Rather than being prescriptive about what and how to use design tokens, though, we concentrate on how we use them for this project. If you want to call them design tokens, that’s fine with us — but it’s not the main point. 
  3. Why html and not :root? Solely because the Javascript polyfill we use to support CSS variables with Internet Explorer 11 requires definitions on the HTML or body element, and does not work if we use :root 
  4. Too bad about the media query for prefers-color-scheme needing to be declared in its own group. The repetition hurts a little bit but luckily the lists of colors are small.