You’ve just rolled out an important new feature on your platform, and it’s time to answer the all-important question: is it getting the results you want? If you’ve set up an analytics tool, you can look at performance indicators like registrations, logins, downloads, or shares. But that kind of quantitative data will only get you so far.

Let’s say that new feature isn’t having the impact you’d hoped for — maybe registrations are lacking or engagement is low. You have a problem you need to solve, but you don’t have any information about why it’s happening. And you may have an entirely different underlying problem you need to address.

Where can you find actionable information? Enter qualitative research.

By answering the why behind what’s happening, qualitative data provides context for problems that surface through quantitative analysis. It helps you uncover the root of the problem you have and can also reveal problems you didn’t even know existed.

In this article, we’ll cover how to use both types of research to inform your platform design.

First, the Numbers: Quantitative Research

When you’re evaluating the performance of a digital platform, a good place to start is the cold, hard numbers. Quantitative research provides numerical data that can indicate, at a glance, whether your platform is meeting your business objectives. It can also show the scale of any problems and help prioritize which ones to address.

One major benefit of quantitative data is benchmarking. Tracking your data over time reveals whether UI changes are producing the results you want — and can help you measure the ROI of your efforts. You can also compare your data to an industry benchmark or a competitor’s stats as a barometer for your own performance.

Here are some examples of quantitative research methods:

Web analytics

This data describes what people are doing with your platform: where they go, what they click on, what features they use. It’s good for finding problems and monitoring the performance of content or features.

A/B testing

Here, you’re using experiments to compare different UI designs. By creating two live versions of the same element, like a call-to-action button, you can see which one performs best. Learn more in our article on A/B testing.

Surveys and questionnaires

Surveys let you gather information about your users’ preferences, attitudes, and behaviors, and they can produce a combination of quantitative and qualitative data. For easy-to-capture numerical data, use techniques like ratings and multiple-choice questions.

Usability testing

By measuring user experience with hard data, you can test how easy (or not) a platform feature is to use. Let’s say you just released a reminder function, and you want to know if users can create a reminder in two minutes or less. You can run a test where you ask participants to set a reminder, and measure what percentage are able to complete the task within two minutes.

Now that you’ve got a sense of what users are doing on your platform, let’s look at ways to learn why and how they’re doing it.

Now for the Words: Qualitative Research

Qualitative research can help you investigate why something is happening, identify ways to fix problems, and even determine whether you should phase out a feature or redesign it. Using detailed, contextual descriptions of users’ experiences, you can dive deeper into exactly which elements are working well and which are problematic.

Quantitative and qualitative research both provide useful data, but they’re more powerful when used together.

Unlike with quantitative research, you don’t need a ton of data points to get usable info. For example, if you see five customers in a row walk into the corner of a display in a retail store’s entrance, you can safely assume that most visitors will do the same thing.

You may be avoiding qualitative data because it seems expensive. And some techniques, like focus groups, require a greater investment than others. But, because you don’t need an enormous amount of data, qualitative research can be very cost-effective. It might even save you money by helping you identify and fix problems faster.

Here are some examples of qualitative research methods:

User Interviews

There are a number of different ways to handle user interviews, depending on the type and specificity of info you’re looking for. Here are a few:

• Talk to a subset of your platform users and ask what they like, don’t like, and why. What could be improved?
• Listen to users narrate their experience as they move through your platform, to learn how they feel about particular elements or tasks.
• Give test subjects a post-task survey, to capture their experiences while they’re fresh.

Focus Groups

These are similar to user interviews, but they’re done in a group setting. The advantage of a group is that it can often generate more feedback, as people tend to open up when they hear the experiences of others. Just be sure you have a moderator who gives everyone a chance to speak.

Field Studies

What people say they do… is often not what they actually do. Watching platform users in their natural environment can reveal gaps in your understanding of the user experience. You can use direct observation, interviews, contextual inquiry, and usability tests to learn how people do things and why they do them in particular ways.

Diary Study

This method asks users to document their experiences over time, making it useful for understanding longer-term behaviors. You can learn things like what motivates people to use certain features, what they’re trying to accomplish, how they feel, and what their overall journey looks like.

User Surveys

As opposed to quantitative surveys, qualitative surveys use open-ended questions to learn what users think and feel in their own words. One common pitfall: avoid leading questions. Instead of asking, say, “How easy was it to find the info you needed?”, ask “Describe your experience looking for that information.”

Like Peanut Butter & Jelly

Quantitative and qualitative research both provide useful data, but they’re more powerful when used together. Remember that quantitative data can tell you when there’s a problem with your platform design, but you’ll need qualitative data to know how to fix it.

Chances are, you’ll use them at different times. Qualitative research can be done during the initial design phase, once you have a working product, or during a redesign. It’s especially valuable at the beginning of a design process because it can help you focus on what your users need and why. Quantitative research is generally done only when you have a working product (either at the beginning or end of a design cycle), so you can measure the results of a design or change.

Want to learn more about how data-driven design can improve your platform performance? We’d love to help. Contact us today to schedule a call.

If you’ve been tossing around these two terms interchangeably, it’s okay. We won’t hold it against you. With some overlapping features and functionality, websites and digital platforms are easy to confuse at first glance.

In reality, they provide very different user experiences — and knowing the difference can be crucial to meeting your business needs.

How are Websites and Platforms Different?

The fundamental difference between a website and a digital platform lies in how you approach user engagement. Websites provide one-way engagement, with users ingesting whatever content the website delivers. Platforms offer reciprocal engagement, with interactions between a platform and its users generating personalized experiences.

Websites rely on implied audience data capture, meaning that users are grouped into broad buckets. If, say, lots of people click on a particular article, the site will assume that most visitors are interested in that topic and will feature it prominently. Essentially, websites are always working with the majority, not the individual.

By contrast, platforms use expressed data capture, where users provide identifying information by registering and logging in. Once someone becomes an authenticated user, you can learn about them directly through multiple touchpoints. That might include filling out forms, participating in discussions, adding comments, completing quizzes or surveys, or bookmarking content. By supplying a platform with real data, users get experiences tailored specifically for them.

Personalized data also allows platforms to streamline business workflows. Take HR processes, for example. When someone logs into a company intranet, they could receive a reminder to complete any unfinished HR forms — a tool that’s convenient and efficient for both the employee and the HR department.

Website Examples

Users generally can’t personalize anything on websites; they visit them for information. Here a few kinds of traditional websites:

• Editorial news: MSNBC, Buzzfeed, The New York Times
• Non-profits: United Way Worldwide, Tourism Saskatoon, Girls Who Code
• Marketing: Well, this one that you are reading right now 🙂

Platform Examples

Platforms encourage users to actively contribute to the digital experience. Here are some examples of what you can do with a platform:

• Amazon: lets you shop faster and more efficiently with personalized recommendations
• Wingspans: uses personalized content discovery to help students explore careers
• MyFund: an easy-to-use, mobile-friendly web app for charitable donations
• Company intranet: provides digital interactions that enhance company culture
• Mirror: customizes workouts based on your goals, preferences, and performance

The Impact of Engagement

Owners of both websites and platforms are generally aiming to increase engagement as a measure of success. But what does that look like?

For a website, increased engagement is indicated by metrics like increased page views, longer “time on page” stats, lower bounce rates, and higher conversions (such as contact form completions or button clicks). Note that all of those metrics point to things that benefit website owners, not users.

News sites want more page views and longer page sessions so they can sell more advertising. Business sites get people to download whitepapers or fill out contact forms, generating sales leads. These are marketing websites designed to capture users’ interest. When a user clicks on a call to action, it shows they want to know more about what the site is advertising.

Platforms are more likely than websites to turn users into loyal brand ambassadors because they get something of value in return.

Once someone engages with a digital platform’s content, however, a two-way conversation begins. The goal is not to just push out content, but to ensure the audience interacts with it. That’s why platforms measure engagement in terms of personalization, community building, and loyalty metrics — things that indicate whether the platform is meeting the needs of both owner and users.

Platforms are also more likely than websites to turn users into loyal customers and brand ambassadors. To get someone to be an advocate for your company, they need to get something of value in return. Websites provide information that’s convenient, but users aren’t getting anything personal from the experience. A platform, by contrast, provides a highly personal connection between a business and its audience.

Which One is Right For You?

The answer, as with many things business-related, is that it depends on your goals.

The purpose of a website is to get users to consume content and return to the site to consume more. If you mainly need an informational site that serves as marketing for your business, a website is likely a good fit.

But what if you need more than that? Maybe community-building is important for your business, whether you need the network effects of a large user base (like social media) or you’re looking to increase employee engagement (as with an intranet). If your business goals require truly understanding your users and building meaningful two-way relationships, you need a digital platform.

In the end, it comes down to how much you need to personalize the user experience to support your business goals, and whether the extra engagement will provide a real return on investment. If you’re pushing out content for marketing purposes, go with a website. If personalization and loyalty are core factors in your business success, build a digital platform.

Looking for a partner to build the right platform for your business? Contact us today to learn how we can help.

You may have heard the old adage, “A website is never done.” Even the best digital platforms go through multiple rounds of changes, updates, and a complete overhaul now and then. Because even if your platform is already good, there’s always something you can do to improve the user experience and better support your business goals.

The key is figuring out which changes truly result in improvements, and which are a waste of your money and time.

Why You Need A/B Testing

Here are a few use cases where A/B testing can deliver crucial info:

• You’re redesigning your platform with new branding, new content, or new architecture.
• You’re looking to expand your platform with a new service or feature.
• You need data to share with other stakeholders to validate content-related activities.
• You need to increase engagement or conversion rates to achieve your business goals.

Whatever the business case, you must understand how users interact with your platform and how its features impact their experience, in order to make informed decisions about platform design and content.

Too often, companies evaluate changes with internal stakeholders instead of real users. In the end, you may go through a lot of development work without knowing if the changes you’re making will result in something impactful. Instead, with less time and fewer resources, __you can use A/B testing with your actual audience to find out definitively what’s effective and what’s not. __

How A/B Testing Helps Your Platform

In addition to helping maximize the effectiveness and minimize the resources invested in platform redesign, A/B testing provides invaluable short- and long-term benefits:

Increase Conversions

Probably the number-one goal for most redesign efforts, increasing conversion rate is one of the most robust uses of A/B testing. Rather than guessing at what makes users complete a registration form or take a desired action, you get hard data to confirm whether a change truly produces a lift in conversions.

Improve User Engagement & Retention

Bounce rate is often a key indicator of user experience and can have a significant impact on your conversion goals. Testing multiple elements of a particular page can help you find visitor pain points and improve their overall experience, ultimately getting them to spend more time on your site.

Learn About Your Audience

By progressively testing which elements your users gravitate to (or from), you can learn a little more about your audience at each step, and then use that data to inform future design and content.

Road-Test New Features

Before you introduce a new feature, launching it as an A/B test can show how your audience is likely to react. You’ll get hard and fast data in a real-world environment with less risk.

Personalize User Experiences

You can use A/B testing as a way to identify steps toward platform personalization, to understand which forms of personalization could potentially increase user engagement.

What Should You Test?

A/B testing can be used for everything from full page designs to single content elements. Even small and simple changes can significantly impact the user experience and, consequently, your engagement and conversion rates.

When Humana A/B tested a website banner, the version with pared-down copy and a different photo increased click-throughs by 433 percent! In a second test, changing the call-to-action (CTA) copy increased click-throughs by a further 192 percent, showing that even subtle word changes can boost engagement.

How do you figure out what to test? Examining quantitative or qualitative data will help you identify potential pain points and give you a basis for experimentation. Maybe your homepage has an unusually high bounce rate, or users are providing negative feedback on your sign up process. Once you’ve identified an issue, form a hypothesis to test: define a problem, propose a solution, and identify metrics for success or failure.

Whatever you include in your testing plan, focus on things that are most likely to impact the metric you’re trying to improve. For instance, if you want to increase conversion rate, you might test the design or placement of a CTA.

Here are some commonly tested elements:

• Headlines and copywriting: length, language, and detail
• CTAs: word choice, placement, button color/size/shape
• Navigation: nav bar placement, content groupings, dropdown options
• Product pages: placement of images, product description length and format
• Landing pages: photography, amount of copy, visual design, placement of CTA

One caution: if you’re testing multiple elements simultaneously, make sure they’re distinct enough that they don’t affect each other and impact the results of each test. Your results should be related only to the options you’re presenting, so there’s a clear understanding of what exactly is influencing your audience.

One Last Word of Advice

In the end, one form of testing alone is never a panacea for improving your platform. While A/B testing provides valuable data, it has limitations, too. Most importantly, unlike qualitative analysis, it doesn’t explain the why behind your measured results. Also, the data produced is only relevant to the specific area you’re testing, versus open-ended user testing that could surface other challenges hindering your platform’s performance.

That’s why qualitative feedback is still vitally important for your site — it surfaces things you can’t learn from numbers alone (like a user not finding you trustworthy or credible). A/B testing can give you relatively quick and easy ways to improve your user experience, but it doesn’t give you every answer you need.

Your business never stands still, and your audience is always evolving and changing. We’re here to help you keep looking forward. Contact us today to talk about optimizing your platform experience.

In the age of hyper-personalization by the likes of Amazon and Netflix, customized user experiences are now table stakes for digital platforms. Businesses that invest in personalization are rewarded with loyalty and revenue. Those that don’t, get left behind.

But making that investment isn’t a straightforward affair. Many services that pitch themselves as personalization tools don’t even come close to creating a truly customized experience. And today’s savvy web users aren’t fooled:

• 74% of customers feel frustrated when website content isn’t personalized.
• 84% of consumers say being treated like a person, not a number, is important to winning their business.

Where we’ve seen businesses stumble is in substituting personification for true personalization. While personalization involves tailoring content based on direct personal information, personification is based on categories of consumers, not individual people.

Here’s what you need to know about the difference.

Perils of Personification

Gartner defines personification as “the delivery of relevant digital experiences to individuals based on their inferred membership in a defined customer segment, rather than their personal identity.” It’s the digital equivalent of calling someone “buddy” or “champ” because you can’t remember their name. I know that I know you, but I don’t know who you are.

Personification tools can track user behavior and use AI to place users into, say, one of several marketing personas you’ve developed. But in terms of driving meaningful, personalized interactions with users, personification falls down.

Here are a few critical issues with commonly used personification tools:

User Session Data

Information about a user’s interactions with an application is stored temporarily on the application’s server, not the browser.

EXAMPLE: During this session, I see that you’ve visited a piece of content that falls in a specific category. For the rest of your session, I can serve up other content tagged with the same category (often in Featured, Related, or You May Also Like sections).

PROBLEM 1: As soon as the browser session is closed, the user data is lost.

PROBLEM 2: The moment you switch from one device (e.g. mobile) to another (e.g. tablet) you lose all session data.

Contextual Data

Marketing automation or location intelligence software can use AI to gather environmental data about a user to deliver customized content or services.

EXAMPLE: I see that you’re in Los Angeles, California. Knowing your local weather, time zone, and other regional attributes, I can tailor the content you see to be more specific to your area.

PROBLEM: I have to ask you first if I can track your location, and you might say no.

First Party Cookie Data

By storing information about a user’s behavior directly on a domain, site owners can collect analytics data and remember language settings, among other functions.

EXAMPLE: Last time you visited my website, you commented on a certain piece of content. I may even have asked, “Do you want to see more of this type of content?” Now that you’re back, I can serve up newly published content of the same type. I can even feature it right on the homepage.

PROBLEM 1: I need to ask you if I can use cookies with you, and you can say no.

PROBLEM 2: If you clear the cookies in your browser, I’ll lose that valuable data.

PROBLEM 3: Another family member is using the same application on the same device, and now I’m getting mixed signals. This is completely messing with my AI.

Bottom line: personification is not really personalization. Even worse, you may lose your data and have to start from square one. To deliver true personalization, you need first-party data from authenticated users. Instead of guessing who your customer is, get to know who they really are.

Next-Level Personalization

True personalization is difficult to achieve outside of a digital platform, where people register as users (versus just casually visiting a website). Once someone becomes an authenticated user, it’s easier to learn a number of things about them.

83% of consumers are willing to share their data to enable personalized experiences. Platform users in particular are more open to providing personal information, because they’re specifically looking for a customized experience. With that first-party data, you can track preferences and interactions to improve the user experience. And you’re not going to lose the historical data when a user closes a session or clears their cookies.

Here are some key benefits:

• I actually know who you are, and over time I can continue to learn more about you and your interests. Plus, I’ll only lose that data if you quit my tool, service, or platform.
• Your data follows you across any devices where you use my application (mobile, tablet, desktop, etc.).
• I can start a two-way conversation with you, so you can tell me how you want to personalize your experience and what kind of content you want to see.
• I can reach out to you with personalized suggestions, driving more engagement and giving you a reason to return more often.
• While you can always say no to first-party cookies if you have privacy concerns, by signing up for my platform, you’re indicating a level of trust and consent.

Looking for Middle Ground?

In the end, you’ll deliver the best personalization (and earn the most engagement) by building an interactive platform and leveraging first-party data. But what if you have a decent website, and you’re not ready to shift to a platform?

You could approach it as a testing ground for personalization instead. By creating a series of micro-interactions using personification tools, you can test whether your users actually want a personalized experience, and if so, what they want to personalize.

Let’s say you’re a news outlet. You could just let people come and read your content online. At the next level, you can try to guess who they are through personification (via cookie requests, location prompts, etc.). If users are interacting with your prompts, it’s likely they’re interested in having a personalized experience.

Finally, you could build a platform for registered users and offer true personalization. You’ll not only deliver a better user experience, you’ll increase engagement and return visits — not to mention sales and other revenue.

At whatever level you can, go the extra mile and give your users what they want. We’re happy to help! Contact us today to learn more.

While the terminology was first spotlighted by IBM back in 2014, the concept of a composable business has recently gained much traction, thanks in large part to the global pandemic. Today, organizations are combining more agile business models with flexible digital architecture, to adapt to the ever-evolving needs of their company and their customers.

Here’s a high-level look at building a composable business.

What is a Composable Business?

The term “composable” encompasses a mindset, technology, and processes that enable organizations to innovate and adapt quickly to changing business needs.

A composable business is like a collection of interchangeable building blocks (think: Lego) that can be added, rearranged, and jettisoned as needed. Compare that with an inflexible, monolithic organization that’s slow and difficult to evolve (think: cinderblock). By assembling and reassembling various elements, composable businesses can respond quickly to market shifts.

Gartner offers four principles of composable business:

• Discovery: React faster by sensing when change is happening.
• Modularity: Achieve greater agility with interchangeable components.
• Orchestration: Mix and match business functions to respond to changing needs.
• Autonomy: Create greater resilience via independent business units.

These four principles shape the business architecture and technology that support composability. From structural capabilities to digital applications, composable businesses rely on tools for today and tomorrow.

So, how do you get there?

Start With a Composable Mindset…

A composable mindset involves thinking about what could happen in the future, predicting what your business may need, and designing a flexible architecture to meet those needs. Essentially, it’s about embracing a modular philosophy and preparing for multiple possible futures.

Where do you begin? Research by Gartner suggests the first step in transitioning to a composable enterprise is to define a longer-term vision of composability for your business. Ask forward-thinking questions, such as:

• How will the markets we operate in evolve over the next 3-5 years?
• How will the competitive landscape change in that time?
• How are the needs and expectations of our customers changing?
• What new business models or new markets might we pursue?
• What product, service, or process innovations would help us outpace competitors?

These kinds of questions provide insights into the market forces that will impact your business, helping you prepare for multiple futures. But you also need to adopt a modular philosophy, thinking about all the assets in your organization — every bit of data, every process, every application — as the building blocks of your composable business.

…Then Leverage Composable Technology

A long-term vision helps create purpose and structure for a composable business. Technology is the tools that bring it to life. Composable technology begets sustainable business architectures, ready to address the challenges of the future, not the past.

For many organizations, the shift to composability means evolving from an inflexible, monolithic digital architecture to a modular application portfolio. The portfolio is made up of packaged business capabilities, or PBCs, which form the foundation of composable technology.

The ABCs of PBCs

PBCs are software components that provide specific business capabilities. Although similar in some respects to microservices, PBCs address more than technological needs. While a specific application may leverage a microservice to provide a feature, when that feature represents a business capability beyond just the application at hand, it is a PBC.

Because PBCs can be curated, assembled, and reassembled as needed, you can adapt your technology practically at the pace of business change. You can also experiment with different services, shed things that aren’t working, and plug in new options without disrupting your entire ecosystem.

When building an application portfolio with PBCs, the key is to identify the capabilities your business needs to be flexible and resilient. What are the foundational elements of your long-term vision? Your target architecture should drive the business outcomes that support your strategic goals.

Build or Buy?

PBCs can either be developed internally or sourced from third parties. Vendors may include traditional packaged-software vendors and nontraditional parties, such as global service integrators or financial services companies.

When deciding whether to build or buy a PBC, consider whether your target capability is unique to your business. For example, a CMS is something many businesses need, and thus it’s a readily available PBC that can be more cost-effective to buy. But if, through vendor selection, you find that your particular needs are unique, you may want to invest in building your own.

Real-World Example

While building a new member retention platform for a large health insurer, we discovered a need to quickly look up member status during the onboarding process. Because the company had a unique way of identifying members, it required building custom software.

Although initially conceived in the context of the platform being created, a composable mindset led to the development of a standalone, API-first service — a true PBC providing member lookup capability to applications across the organization, and waiting to serve the applications of the future.

A Final Word

Disruption is here to stay. While you can’t predict every major shift, innovation, or crisis that will impact your organization, you can (almost) future-proof your business with a composabile approach.

Start with the mindset, lay out a roadmap, and then design a step-by-step program for digital transformation. The beauty of an API-led approach is that you can slowly but surely transform your technology, piece by piece.

If you’re interested in exploring a shift to composability, we’d love to help. Contact us today to talk about your options.

Second chances are expensive. Why? Because it takes five positive experiences to counterbalance the effects of a negative one. If someone’s first experience with your platform is disappointing, you have a long way to go to win back their confidence — if they even complete your sign-up form.

More than 67% of site visitors will completely abandon a sign-up process if they encounter any complications. If you’re lucky, maybe 20% of them will follow up with your company in some way. Whether you’re trying to get people to sign up for your mobile app, e-commerce platform, or company intranet, you must make the process as seamless as possible.

Here are six tips to reduce sign-up friction for your platform.

1. Use a Single Sign On Service

This is crucial for larger platforms that are part of a vast ecosystem with multiple logins, like a complex hospital platform providing access to multiple systems. On the other hand, for a basic paywall, you may want to manage user info yourself. The key is to think strategically about what your systems may look like down the road and how unwieldy your sign-up process may become.

Here are a few things to consider:

Pros

• Single Sign On (SSO) reduces password fatigue and simplifies password management for users
• It allows businesses to quickly provide or revoke employees’ system access
• It lowers the security risk for customers, vendors, and partners
• It improves identity protection with the ability to add multi-factor verification
• The number of available off-the-shelf SSO products makes it more cost effective to implement

Cons

• When SSO is down, access to all platform systems becomes more difficult
• It may introduce a security flaw, as a stolen password from a single user can provide access to multiple systems — which makes multi-factor verification more important
• SSO using social network sign in may not work in corporate systems where social media platforms are blocked by IT

In the end, the advantages of SSO significantly outweigh the downsides. But you’ll likely need expert guidance when planning and implementing SSO to ensure you reap the benefits while minimizing the risks.

2. Keep It Short

More than a quarter of users who abandon online forms do so because they’re too long. To maximize the number of sign-ups, minimize the steps involved.

How do you decide which fields to keep? Try asking, “If I didn’t have this piece of information, would I still be able to provide a good customer experience?” If it’s something you don’t really need to know, then don’t ask.

Here are two more ways to shorten form length:

• Use only required fields. Save anything optional for after sign-up, with prompts to help users “complete” their profile. Hide any repeated fields, like email or password verification. Display one email field, then, once it’s being entered, display the second one below it. Better yet, don’t force people to type things twice.
• Still having a hard time cutting fields? Consider this: Expedia dropped one form field and gained $12 million per year. If a piece of data is labelled as optional, it shouldn’t be in your sign-up form.

3. Use a Single Column Layout

In general, your form should adhere to this core UX principle:

Make the user experience smoother, faster, and better; not messier, slower, and worse.

The simpler the flow of your form, the faster and easier it feels to fill out. Here are a few tips:

• Put all your fields in a logical order.
• Make it easy to read and enter information in a smooth flow from top to bottom.
• Put labels above the input fields, not to the left (as many forms do).
• Avoid placing fields side by side, except for items where it tends to be the norm, such as city, state, and zip code.

4. Play Nice with Autofill

Nothing makes our sanguine CEO spout expletives faster than a platform that doesn’t allow browser-suggested passwords. While many of those suggested passwords are long strings of characters saved securely to the browser, the letter/number/special character combination may not meet your platform’s arbitrary standards.

In addition, some accessibility checkers will flag fields where autofill is turned off, indicating a possible issue for people with disabilities.

Here are a few more ways to make the experience smoother:

• In phone input fields, automatically fill in dashes. In date fields, fill in slashes
• Transition from one field or step to the next automatically
• Don’t use select lists for date values like months or years

And, don’t forget to test the autofill function on both a desktop and phone — the experience can be very different between the two.

5. Allow Guest Checkout for eCommerce

To put it bluntly, don’t get in the way of someone spending money on your site. Instead, make it easy to open an account just by creating a password. Or, create a new user account automatically with the info you have, then send users an email with instructions on how to finalize the sign-up process.

What we’ve seen work well: after a successful shopping experience, follow up with an email to the customer that sells the benefits of having an account and asks if they would like to activate theirs.

6. Don’t Use a CAPTCHA

That’s right, we said it. It’s time to get rid of CAPTCHA on your sign-up form. Here are three good reasons why:

• There are too many ways to counter CAPTCHA, especially as AI evolves
• CAPTCHA puzzles are getting harder and harder for humans to solve
• Use of CAPTCHA has been shown to increase form abandonment

Instead, confirm any new account the tried-and-true way: with an email to the registered address. And consider if there are ways to clean up your security features on the back end, instead of presenting barriers to customers upon sign-up.

Don’t put the onus on the people who are trying to give you money. Put it on your systems instead.

You Only Get a First Impression Once

As the gateway to onboarding users, the sign-up process is the most crucial piece of your user experience to get right. Whether your goal is to acquire and retain customers, or to engage and inform employees, your success depends on getting your target audience past the initial sign-up hurdle. If their first task is difficult, it doesn’t bode well for the rest of the experience.

Don’t let your sales and marketing be better than your user onboarding. Once someone has decided your platform offers what they need, you’re more than halfway to converting them into a user. Just make sure your sign-up process lives up to your marketing promises.

Not long ago, company intranets were little more than a repository for shared files, general announcements, and the all-important list of holiday office closures. Today, the humble intranet has evolved as a way to enhance internal communication and employee engagement and to help workers do their jobs.

While organizations tend to have more content- and feature-rich intranets these days, many are missing one crucial element: a mobile-optimized version. As a result, they can exclude a large proportion of workers—including the 80% of people who make up today’s Deskless Workforce.

Top “deskless” industries include education, healthcare, retail, hospitality, and transportation, employing many of the frontline workers we all depend on.

One of our own clients, a large hospital system, told us that 70% of their workforce doesn’t sit at a desk, nor do they use a computer every day. And if 70% of their employees can’t easily access the company intranet, they’re not provided equitable access to the same resources as everyone else.

Why Mobile Matters Today

In addition to the challenges of communicating with deskless workers, the rise of remote work and the growing number of Millennials in the workforce are helping to drive an increased demand for mobile-optimized or employee-app versions of intranets.

Consider this: the average American spends more than 5 hours a day on their phone (and it’s almost always within reach). In addition, nearly half of smartphone users access the internet primarily on their phones versus a desktop computer, laptop, or tablet. Those numbers are even higher for Millennials, who currently make up 35% of the US workforce.

Mobile communication plays an essential role in our personal lives. To serve employees, company intranets must offer the same ease-of-use, convenience, and capability to our work lives. The intranet must go beyond the desktop box to where workers are.

The Benefits of an Inclusive Intranet

In addition to facilitating access, mobile technology offers a number of unique benefits that can significantly improve employee engagement and productivity and help reduce frustration.

Here are some of the key benefits of a mobile-optimized intranet:

Real-Time Push Notifications

Imagine there’s an emergency situation in your facility, or an important update that staff need to receive immediately. You can push the information straight to their phone, enabling real-time communication across your workforce. Unlike emails, most push notifications get read within the first 3 minutes after they’re received.

Broader Access for BYOD

As more and more organizations support remote work and flexible schedules—while fewer and fewer provide company smartphones—the “Bring Your Own Device” trend has become more prevalent. Many of today’s employees are using personal devices to access work-related resources and systems. And, as we noted earlier, most of the time that means they’re using a smartphone.

Freedom from Workstations

In some organizations, employees are still sharing desktop workstations that we might charitably describe as “clunky.” It’s inefficient and inconvenient, especially when multiple people have to go out of their way to get to a workspace. A mobile-optimized intranet gives everyone fast and easy access to the same resources, wherever they are.

Two-Way Communication

Intranets have traditionally been top-down communication platforms, focusing primarily on the needs of employers, not employees. Today, companies looking to increase engagement have shifted to a new mindset: communication tools are no longer for talking to employees, but talking with them.

Mobile-optimized platforms and mobile apps help facilitate two-way conversations, especially with features like built-in chatting or social forums where employees can like and comment on posts. This allows companies to have more personalized conversations with employees in addition to collecting valuable, on-the-spot feedback from the front lines.

Remote Doesn’t Feel So Remote

Without regular in-person interaction, remote workers often feel isolated and less engaged. By offering more of an app-like experience with ongoing communication, an intranet can help recreate an environment that fosters idea sharing and boosts morale. It also means that employees who work at home, or don’t have access to a computer, won’t feel uninformed and isolated from the rest of the team.

Better User Experience

If you’re looking to use your intranet as a tool for engagement, you’ll get the best results from an employee app. An app lets you take advantage of mobile-native tools, like location detection and offline access, which let you both customize content and make it more readily available. The improved user experience, speed, and features are the reasons why most people prefer apps to websites.

An Intranet for Everyone

Like many organizations, the purpose of your intranet might be to create a more engaged workforce or improve employee productivity. But if most of your workers either can’t or don’t access the content, you’re not going to achieve your goals.

As cultures, companies, and industries move towards creating more inclusiveness and equity, organizations across the world are looking for ways to meet the needs of their employees. One way to address your team’s needs and expectations is to start by ensuring your internal resources are truly benefiting everyone who relies on them.

In 2023, Oomph’s design for the Lifespan Intranet was selected by the Nielsen Norman Group as one of the Ten Best Intranets globally.

If you can’t measure it, you can’t improve it. It’s true for your business, and it’s true for your digital platform. Yet we’ve seen organizations from startups to enterprises neglect to incorporate measurement into their platform strategy.

Data shows you what is and isn’t working in your platform. And, unlike most websites, platforms provide detailed information about known users across specific touchpoints — accurate, first-party data that doesn’t rely on cookies or fuzzy analytics. Actionable insights await; you just have to know what you’re measuring for.

Here’s how to take a strategic approach to measuring platform performance.

Start From the Top

Measuring the success of your platform involves the same general principles used in strategic planning. Start from the top and work your way down:

• What are your organization’s overall goals?
• What are the business objectives that drive those goals?
• What does your platform need to accomplish, in order to support those objectives?
• What is the core purpose your platform must meet to achieve its goals?

Once you define your platform’s core purpose, you can identify which metrics to track. Just make sure that if you move the needle on those metrics, you’re truly moving the needle for your business.

Here’s an example: Let’s say you run a healthcare system whose primary goal is to save lives. To meet that goal, your employees need speedy access to your procedures for patient care. So, you build an intranet platform in order to provide the fastest possible access to that critical information. Your core purpose is to make sure this information is as easy to find as possible, so employees have critical information at critical moments.

What Should You Measure?

You’ve identified your platform’s core purpose. Next question is, what is the core interaction your platform relies on to achieve that purpose? What’s the single most important thing you need users to do? That action determines how you define an “active” platform user, and it’s the key driver for what you should measure.

Just like with social media, where the term “monthly active users” is widely used but has many different meanings, business platforms often have unique definitions of an active user. A company intranet focused on employee engagement might define an active user as someone who posts content a certain number of times per month. A business platform offering exclusive deals to attract new customers might define an active user as a customer who redeems at least one deal per year.

Whatever your platform’s purpose is, you need to be tracking metrics related to your definition of an active user, in order to optimize the core interaction that drives your business goals.

Examples of Useful Metrics

Before we dive into the list, there’s a caveat: Just because you can measure a ton of metrics doesn’t mean you should. Too much data can be distracting, and paying attention to too many metrics can create confusion and cause analysis paralysis. The goal of measurement isn’t to manage a dashboard; it’s to make decisions and take actions that drive positive business outcomes.

Choose a primary goal, define a core objective and active user, and aim for up to five core metrics to measure success. Here are some examples:

Growth

If your business goals depend on having a large number of platform users, you might use one of the following growth measures:

• Total number of users over time
• Rate at which new people join the platform
• Rate of user attrition in a given period

Reach

This is useful for platforms where you’re looking to engage a certain proportion of a population, such as your employees or your customer base. You might track:

• Total number of registered users
• Percentage of total registered users that are active
• Total logins versus unique logins

Engagement

Engagement covers a lot of ground, and it’s easy to get lost in the weeds. Focus on the metrics that tell you how people are responding to your efforts to engage them at various touchpoints. Here are some examples:

• Number of posts per user / Average number of responses per post
• Number of unique users completing an action, like submitting a form
• Number of support requests (are users confused?)

Begin at the Beginning

It’s a mistake to think about measurement only after you’ve built your platform. Remember, platform measurement isn’t as easy as dropping in base Google Analytics code. Platform metrics are deep and nuanced, so you need to think strategically from the start. Plan the key metrics up front, and incorporate measurement into your platform roadmap from the beginning.

Your game plan, in a nutshell:

1. Decide what to measure
2. Implement tracking capabilities
3. Measure platform performance
4. Analyze the results and find actionable insights
5. Make decisions: what’s working, and what needs to change?

Establishing measurement practices early on enables you to continually track, analyze, and optimize performance over the life of your platform. Already launched? Fear not. It’s never too late to implement measurement techniques to optimize platform performance.

If you’re thinking about how to be more strategic with platform measurement, we’d love to help. Feel free to reach out with any questions you have.

Why are microservices growing in popularity for enterprise-level platforms? For many organizations, a microservice architecture provides a faster and more flexible way to leverage technology to meet evolving business needs. For some leaders, microservices better reflect how they want to structure their teams and processes.

But are microservices the best fit for you?

We’re hearing this question more and more from platform owners across multiple industries as software monoliths become increasingly impractical in today’s fast-paced competitive landscape. However, while microservices offer the agility and flexibility that many organizations are looking for, they’re not right for everyone.

In this article, we’ll cover key factors in deciding whether microservices architecture is the right choice for your platform.

What’s the Difference Between Microservices and Monoliths?

Microservices architecture emerged roughly a decade ago to address the primary limitations of monolithic applications: scale, flexibility, and speed.

Microservices are small, separately deployable, software units that together form a single, larger application. Specific functions are carried out by individual services. For example, if your platform allows users to log in to an account, search for products, and pay online, those functions could be delivered as separate microservices and served up through one user interface (UI).

In monolithic architecture, all of the functions and UI are interconnected in a single, self-contained application. All code is traditionally written in one language and housed in a single codebase, and all functions rely on shared data libraries.

Essentially, with most off-the-shelf monoliths, you get what you get. It may do everything, but not be particularly great at anything. With microservices, by contrast, you can build or cherry-pick optimal applications from the best a given industry has to offer.

Because of their modular nature, microservices make it easier to deploy new functions, scale individual services, and isolate and fix problems. On the other hand, with less complexity and fewer moving parts, monoliths can be cheaper and easier to develop and manage.

So which one is better? As with most things technological, it depends on many factors. Let’s take a look at the benefits and drawbacks of microservices.

Advantages of Microservices Architecture

Companies that embrace microservices see it as a cleaner, faster, and more efficient approach to meeting business needs, such as managing a growing user base, expanding feature sets, and deploying solutions quickly. In fact, there are a number of ways in which microservices beat out monoliths for speed, scale, and agility.

Shorter time to market

Large monolithic applications can take a long time to develop and deploy, anywhere from months to years. That could leave you lagging behind your competitors’ product releases or struggling to respond quickly to user feedback.

By leveraging third-party microservices rather than building your own applications from scratch, you can drastically reduce time to market. And, because the services are compartmentalized, they can be built and deployed independently by smaller, dedicated teams working simultaneously. You also have greater flexibility in finding the right tools for the job: you can choose the best of breed for each service, regardless of technology stack.

Lastly, microservices facilitate the minimum viable product approach. Instead of deploying everything on your wishlist at once, you can roll out core services first and then release subsequent services later.

Faster feature releases

Any changes or updates to monoliths require redeploying the entire application. The bigger a monolith gets, the more time and effort is required for things like updates and new releases.

By contrast, because microservices are independently managed, dedicated teams can iterate at their own pace without disrupting others or taking down the entire system. This means you can deploy new features rapidly and continuously, with little to no risk of impacting other areas of the platform.

This added agility also lets you prioritize and manage feature requests from a business perspective, not a technology perspective. Technology shouldn’t prevent you from making changes that increase user engagement or drive revenue—it should enable those changes.

Affordable scalability

If you need to scale just one service in a monolithic architecture, you’ll have to scale and redeploy the entire application. This can get expensive, and you may not be able to scale in time to satisfy rising demand.

Microservices architecture offers not only greater speed and flexibility, but also potential savings in hosting costs, because you can independently scale any individual service that’s under load. You can also configure a single service to add capability automatically until load need is met, and then scale back to normal capacity.

More support for growth

With microservices architecture, you’re not limited to a UI that’s tethered to your back end. For growing organizations that are continually thinking ahead, this is one of the greatest benefits of microservices architecture.

In the past, websites and mobile apps had completely separate codebases, and launching a mobile app meant developing a whole new application. Today, you just need to develop a mobile UI and connect it to the same service as your website UI. Make updates to the service, and it works across everything.

You have complete control over the UI — what it looks like, how it functions for the customer, etc… You can also test and deploy upgrades without disrupting other services. And, as new forms of data access and usage emerge, you have readily available services that you can use for whatever application suits your needs. Digital signage, voice commands for Alexa… and whatever comes next.

Optimal programming options

Since monolithic applications are tightly coupled and developed with a single stack, all components typically share one programming language and framework. This means any future changes or additions are limited to the choices you make early on, which could cause delays or quality issues in future releases.

Because microservices are loosely coupled and independently deployed, it’s easier to manage diverse datasets and processing requirements. Developers can choose whatever language and storage solution is best suited for each service, without having to coordinate major development efforts with other teams.

Greater resilience

For complex platforms, fault tolerance and isolation are crucial advantages of microservices architecture. There’s less risk of system failure, and it’s easier and faster to fix problems.

In monolithic applications, even just one bug affecting one tiny part of a single feature can cause problems in an unrelated area—or crash the entire application. Any time you make a change to a monolithic application, it introduces risk. With microservices, if one service fails, it’s unlikely to bring others down with it. You’ll have reduced functionality in a specific capacity, not the whole system.

Microservices also make it easier to locate and isolate issues, because you can limit the search to a single software module. Whereas in monoliths, given the possible chain of faults, it’s hard to isolate the root cause of problems or predict the outcome of any changes to the codebase.

Monoliths thus make it difficult and time-consuming to recover from failures, especially since, once an issue has been isolated and resolved, you still have to rebuild and redeploy the entire application. Since microservices allow developers to fix problems or roll back buggy updates in just one service, you’ll see a shorter time to resolution.

Faster onboarding

With smaller, independent code bases, microservices make it faster and easier to onboard new team members. Unlike with monoliths, new developers don’t have to understand how every service works or all the interdependencies at play in the system.

This means you won’t have to scour the internet looking for candidates who can code in the only language you’re using, or spend time training them in all the details of your codebase. Chances are, you’ll find new hires more easily and put them to work faster.

Easier updates

As consumer expectations for digital experiences evolve over time, applications need to be updated or upgraded to meet them. Large monolithic applications are generally difficult, and expensive, to upgrade from one version to the next.

Because third-party app owners build and pay for their own updates, with microservices there’s no need to maintain or enhance every tool in your system. For instance, you get to let Stripe perfect its payment processing service while you leverage the new features. You don’t have to pay for future improvements, and you don’t need anyone on staff to be an expert in payment processing and security.

Disadvantages of Microservices Architecture

Do microservices win in every circumstance? Absolutely not. Monoliths can be a more cost-effective, less complicated, and less risky solution for many applications. Below are a few potential downsides of microservices.

Extra complexity

With more moving parts than monolithic applications, microservices may require additional effort, planning, and automation to ensure smooth deployment. Individual services must cooperate to create a working application, but the inherent separation between teams could make it difficult to create a cohesive end product.

Development teams may have to handle multiple programming languages and frameworks. And, with each service having its own database and data storage system, data consistency could be a challenge.

Also, when you choose to leverage numerous 3rd party services, this creates more network connections as well as more opportunities for latency and connectivity issues in your architecture.

Difficulty in monitoring

Given the complexity of microservices architecture and the interdependencies that may exist among applications, it’s more challenging to test and monitor the entire system. Each microservice requires individualized testing and monitoring.

You could build automated testing scripts to ensure individual applications are always up and running, but this adds time and complexity to system maintenance.

Added external risks

There are always risks when using third-party applications, in terms of both performance and security. The more microservices you employ, the more possible points of failure exist that you don’t directly control.

In addition, with multiple independent containers, you’re exposing more of your system to potential attackers. Those distributed services need to talk to one another, and a high number of inter-service network communications can create opportunities for outside entities to access your system.

On an upside, the containerized nature of microservices architecture prevents security threats in one service from compromising other system components. As we noted in the advantages section above, it’s also easier to track down the root cause of a security issue.

Potential culture changes

Microservices architecture usually works best in organizations that employ a DevOps-first approach, where independent clusters of development and operations teams work together across the lifecycle of an individual service. This structure can make teams more productive and agile in bringing solutions to market. But, at an organizational level, it requires a broader skill set for developing, deploying, and monitoring each individual application.

A DevOps-first culture also means decentralizing decision-making power, shifting it from project teams to a shared responsibility among teams and DevOps engineers. The goal is to ensure that a given microservice meets a solution’s technical requirements and can be supported in the architecture in terms of security, stability, auditing, etc…

3 Paths Toward Microservices Transformation

In general, there are three different approaches to developing a microservices architecture:

1. Deconstruct a monolith

This kind of approach is most common for large enterprise applications, and it can be a massive undertaking. Take Airbnb, for instance: several years ago, the company migrated from a monolith architecture to a service-oriented architecture incorporating microservices. Features such as search, reservations, messaging, and checkout were broken down into one or more individual services, enabling each service to be built, deployed, and scaled independently.

In most cases, it’s not just the monolith that becomes decentralized. Organizations will often break up their development group, creating smaller, independent teams that are responsible for developing, testing, and deploying individual applications.

2. Leverage PBCs

Packaged Business Capabilities, or PBCs, are essentially autonomous collections of microservices that deliver a specific business capability. This approach is often used to create best-of-breed solutions, where many services are third-party tools that talk to each other via APIs.

PBCs can stand alone or serve as the building blocks of larger app suites. Keep in mind, adding multiple microservices or packaged services can drive up costs as the complexity of integration increases.

3. Combine both types

Small monoliths can be a cost-effective solution for simple applications with limited feature sets. If that applies to your business, you may want to build a custom app with a monolithic architecture.

However, there are likely some services, such as payment processing, that you don’t want to have to build yourself. In that case, it often makes sense to build a monolith and incorporate a microservice for any features that would be too costly or complex to tackle in-house.

A Few Words of Caution

Even though they’re called “microservices”, be careful not to get too small. If you break services down into many tiny applications, you may end up creating an overly complex application with excessive overhead. Lots of micro-micro services can easily become too much to maintain over time, with too many teams and people managing different pieces of an application.

Given the added complexity and potential costs of microservices, for smaller platforms with only one UI it may be best to start with a monolithic application and slowly add microservices as you need them. Start at a high level and zoom in over time, looking for specific functions you can optimize to make you stand out.

Lastly, choose your third party services with care. It’s not just about the features; you also need to consider what the costs might look like if you need to scale a particular service.

Final Thoughts: Micro or Mono?

Still trying to decide which architecture is right for your platform? Here are some of the most common scenarios we encounter with clients:

1. If time to market is the most important consideration, then leveraging 3rd party microservices is usually the fastest way to build out a platform or deliver new features.
2. If some aspect of what you’re doing is custom, then consider starting with a monolith and either building custom services or using 3rd parties for areas that will help suit a particular need.
3. If you don’t have a ton of money, and you need to get something up quick and dirty, then consider starting with a monolith and splitting it up later.

Here at Oomph, we understand that enterprise-level software is an enormous investment and a fundamental part of your business. Your choice of architecture can impact everything from overhead to operations. That’s why we take the time to understand your business goals, today and down the road, to help you choose the best fit for your needs.

We’d love to hear more about your vision for a digital platform. Contact us today to talk about how we can help.

How we leveraged Drupal’s native API’s to push notifications to the many department websites for the State.RI.gov is a custom Drupal distribution that was built with the sole purpose of running hundreds of department websites for the state of Rhode Island. The platform leverages a design system for flexible page building, custom authoring permissions, and a series of custom tools to make authoring and distributing content across multiple sites more efficient.

The Challenge

The platform had many business requirements, and one stated that a global notification needed to be published to all department sites in near real-time. These notifications would communicate important department information on all related sites. Further, these notifications needed to be ingested by the individual websites as local content to enable indexing them for search.

The hierarchy of the departments and their sites added a layer of complexity to this requirement. A department needs to create notifications that broadcast only to subsidiary sites, not the entire network. For example, the Department of Health might need to create a health department specific notification that would get pushed to the Covid site, the RIHavens site, and the RIDelivers sites — but not to an unrelated department, like DEM.

Exploration

Aggregator:

Our first idea was to utilize the built in Drupal aggregator module and pull notifications from the hub. A proof of concept proved that while it worked well for pulling content from the hub site, it had a few problems:

1. It relied heavily on the local site’s cron job to pull updates, which led to timing issues in getting the content — it was not in near real-time. Due to server limitations, we could not run cron as often as would be necessary
2. Another issue with this approach was that we would need to maintain two entity types, one for global notifications and a second for local site notifications. Keeping local and global notifications as the same entity allowed for easier maintenance for this subsystem.

Feeds:

Another thought was to utilize the Feeds module to pull content from the hub into the local sites. This was a better solution than the aggregator because the nodes would be created locally and could be indexed for local searching. Unfortunately, feeds relied on cron as well.

Our Solution

JSON API

We created a suite of custom modules that centered around moving data between the network sites using Drupal’s JSON API. The API was used to register new sites to the main hub when they came online. It was also used to pass content entities from the main hub down to all sites within the network and from the network sites back to the hub.

Notifications

In order to share content between all of the sites, we needed to ensure that the data structure was identical on all sites in the network. We started by creating a new notification content type that had a title field, a body field, and a boolean checkbox indicating whether the notification should be considered global. Then, we packaged the configuration for this content type using the Features module.

By requiring our new notification feature module in the installation profile, we ensured that all sites would have the required data structure whenever a new site was created. Features also allowed us to ensure that any changes to the notification data model could be applied to all sites in the future, maintaining the consistency we needed.

Network Domain Entity

In order for the main hub, ri.gov, to communicate with all sites in the network, we needed a way to know what Drupal sites existed. To do this, we created a custom configuration entity that stored the URL of sites within the network. Using this domain entity, we were able to query all known sites and passed the global notification nodes created on ri.gov to each known site using the JSON API.

Queue API:

To ensure that the notification nodes were posted to all the sites without timeouts, we decided to utilize Drupal’s Queue API. Once the notification content was created on the ri.gov hub, we queried the known domain entities and created a queue item that would use cron to actually post the notification node to each site’s JSON API endpoint. We decided to use cron in this instance to give us some assurance that a post to many websites wouldn’t timeout and fail.

Batch API

To allow for time sensitive notifications to be pushed immediately, we created a custom batch operation that reads all of the queued notifications and pushes them out one at a time. If any errors are encountered, the notification is re-queued at the end of the stack and the process continues until all notifications have been posted to the network sites.

New site registrations

In order to ensure that new sites receive notifications from the hub, we needed a site registration process. Whenever a new site is spun up, a custom module is installed that calls out to the hub using JSON API and registers itself by creating a new network domain entity with it’s endpoint URL. This allows the hub to know of the new site and can push any new notifications to this site in the future.

The installation process will also query the hub for any existing notifications and, using the JSON API, get a list of all notification nodes from the hub to add them to it’s local queue for creation. Then, the local site uses cron to query the hub and get the details of each notification node to create it locally. This ensured that when a new site comes online, it will have an up to date list of all the important notifications from the hub.

Authentication

Passing this data between sites is one challenge, but doing it securely adds another layer of complexity. All of the requests going between the sites are authenticating with each other using the Simple Oauth module. When a new site is created, an installation process creates a dedicated user in the local database that will own all notification nodes created with the syndication process. The installation process also creates the appropriate Simple OAuth consumers which allows the authenticated connections to be made between the sites.

Department sites

Once all of the groundwork was in place, with minimal effort, we were able to allow for department sites to act as hubs for their own department sites. Thus, the Department of Health can create notifications that only go to subsidiary sites, keeping them separate from adjacent departments.

Translations

The entire process also works with translations. After a notification is created in the default language, it gets queued and sent to the subsidiary sites. Then, a content author can create a translation of that same node and the translation will get queued and posted to the network of sites in the same manner as the original. All content and translations can be managed at the hub site, which will trickle down to the subsidiary sites.

Moving in the opposite direction

With all of the authorization, queues, batches, and the API’s in place, the next challenge was making this entire system work with a Press Release content type. This provided two new challenges that we needed to overcome:

1. Instead of moving content from the top down, we needed to move from the bottom up. Press release nodes get created on the affiliate sites and would need to be replicated on the hub site.
2. Press release nodes were more complex than the notification nodes. These content types included media references, taxonomy term references and toughest of all, paragraph references.

Solving the first challenge was pretty simple – we were able to reuse the custom publishing module and instructed the queue API to send the press release nodes to the hub sites.

Getting this working with a complex entity like the press release node meant that we needed to not only push the press release node, but we also needed to push all entities that the initial node referenced. In order for it all to work, the entities needed to be created in reverse order.

Once a press release node was created or updated, we used the EntityInterface referencedEntities() method to recursively drill into all of the entities that were referenced by the press release node. In some cases, this meant getting paragraph entities that were nested two, three, even four levels deep inside of other paragraphs. Once we reached the bottom of the referenced entity pile, we began queuing those entities from the bottom up. So, the paragraph that was nested four levels deep was the first to get sent and the actual node was the last to get sent

Conclusion

Drupal’s powerful suite of API’s gave us all the tools necessary to come up with a platform that will allow the State of Rhode Island to easily keep their citizens informed of important information, while allowing their editing team the ease of a create once and publish everywhere workflow.

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:

• Define a color once and in one place and make its definition available to Sass and Twig
• Define color themes once and in one place and make those definitions available to Sass, Twig, and PHP
• Define colors in HSL(), which is more human-readable, making it easy to understand the relationships between colors, while allowing conversion to whatever color space we might need

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

• Allow authors the choice of background colors from defined theme options without controlling foreground colors — this takes the ability to create inaccessible color combinations out of their hands
• Allow authors to design content for their own preferred color scheme (light or dark) and be confident that it will look great for those who use the other mode

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

• A minimum color contrast ratio of 4.5 for accessibility in menus and design components but a higher contrast for main content
• A dark mode that responds to a viewer’s system preference but can also be overridden with local site controls

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 process¹.

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": [ … }
}

JSON

Color Definitions

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

{
  "colors":
    # 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"
    }
  }
}

JSON

There are 46 colors total, but they all follow this pattern². 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:

• name: A human-readable name that can be used in a select list
• hue: How the color might be described
• hsl: The actual color definition in either the HSL() or the HSLA() color space
• needs: What color text would this color need? Light or dark are the values we expect here

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

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 element³:

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);
}

CSS

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 %}
    <li>
      <span class="sg-swatch" style="background: {{ color.hsl }};"></span>
      <span class="sg-label"><b>{{ color.name }}:</b> {{ color.hsl }}</span>
      <span class="sg-code"><code>var(--c__{{ key }})</code></span>
    </li>
  {% endfor %}
</ul>

Twig

A 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.

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:

• Break the theme down into components, like “header”, “nav-main”, and “default” among others
• Name these theme colors with a functional component name — i.e., in the main navigation, a color name might be var(--fc__nav-main__fg) which represents functional color, navigation main, foreground
• Define functional colors in themes as a reference to the colors array

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": { … }
  }
}

JSON

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" }
]

JSON

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;
}

CSS

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;
  }
}

CSS

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 html⁴. 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:

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 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;
}

JavaScript

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:

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:

• Custom CSS properties for color definitions in Sass
• A Twig file with a visual preview of all colors
• Custom CSS properties for functional component colors within defined color themes for light and dark modes
• A Twig file with a visual preview of all themes
• A Twig file with a data table calculating color contrast ratios for all colors in the system, and
• A dynamic drop-down menu in the admin of the sites that allows a site author to choose a color theme

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.