ALEX Go

ALEX Go is a mobile-first version of ALEX BC that is available in English and Spanish.

ALEX Go currently only covers medical plan options and health care account contributions (HSA or FSA), and users can’t create an ALEX ID or save their choices.

There are a couple other distinctions on the product level that impact how we think about writing for this product.

1. ALEX Go is read-only.
2. ALEX Go is a linear experience that has a “back” button, which means that users can repeat/reread screens once they’ve moved forward.

ALEX Go is designed to structurally mirror BC as much as possible, so when adding new content to Go, we generally try to ask the same questions (with the same phrasing) in Go that already exist in the corresponding parts of BC.

Why does this language-level parity matter? Having the same questions in Go and BC is not only about ALEX ID but also making sure we’re giving the same recommendations in both products (v1 of Go omitted a few questions and there were situations where customers noticed BC and Go recommending different plans and were, understandably, not thrilled). We don’t want to unintentionally push certain plans or deter users from particular choices just because the phrasing differs between products.

We want these scripts (and the data they produce) to run in parallel and maintain them with this in mind. However, there is one moment in ALEX Go that does not exist in BC in which we ask users to give us a rough guess of the level of care they might need and then use ballpark medical expenses to make a recommendation.

Additionally, as in BC, ALEX Go customers have the option to include custom eligibility/incentive questions, which appear in ALEX BC as a block of text followed by a question. Because this would force users to scroll forever in a mobile format, the order of this content is flipped in Go. So, users are asked a question and have the option to click on a question mark that pops out the relevant block of text, if they want to read it.

Note: This product design did not have mechanical or self-imposed character limits.

How to Write for ALEX Go

When writing for ALEX Go, prioritize clear, simple messaging over ALEXifying the content. 

In the words of one writer, “Think of Go as the essence of ALEX.” Keywords: friendly, approachable. 

Because of the design constraints above (especially that back button), ALEX Go’s text has less personality and no jokes.

Why?

1. The mobile format requires that we use words more economically. Unlike in BC where we might throw in an extra word or two to ensure a line reads well aloud, we avoid this for our mobile, read-only products.
2. We don’t want to risk annoying the user (or worse, getting in their way) if they opt to return to a past slide on the hunt for helpful information. 

Similarly, avoid using prepositional phrases to introduce new topics. For example, instead of, “To estimate which medical plan could save you the most money, I need to know how much medical care you’ll need,” opt for, “To estimate your costs, I need to know how much medical care you’ll need.”

Note that a conversational BC Alex can occasionally presume a level of social identification with the user (enough to say “we” or “let’s”) but Go should be less presumptuous, and simply offer a service to the user.

Think of each screen as a self-contained unit of meaning. In Go, the user walks themselves through the text, so the focus is clear, concise, self-contained text that can be easily absorbed.

Whenever possible, provide context for why we need X information before asking the user several questions. Let them know they’re answering questions for their own benefit (and specifically what that is).

For example, when asking eligibility questions (because there are a lot of them), each screen includes a subheader specifying the point of the current series of questions: 

Section	Intro text for context
Basic info	To look up your medical plan options, I need to know…
Coverage questions	To see what you’d pay to be on each plan, I need to know…

When ALEX needs to use medical insurance jargon (like deductible), prioritize conveying the meaning and impact over precisely explaining the jargon and then telling the user why it’s relevant to them. Our goal: the information should make sense even if the user doesn’t perfectly understand the jargon.

The deductible example is: “In general, once you spend $XXXX on medical care (the “deductible”), the plan starts covering most of your costs (this is factored into your overall cost estimate).”