direct-file/docs/design/Direct File Design Guidelines & Processes.md

Direct File Design Guidelines & Processes

Product vision

The Direct File user experience and vision is grounded in the following principles:

1. Reduce the cost, time, and psychological burden of filing taxes for taxpayers.
2. Ensure access to essential tax-administered benefits like the Earned Income Tax Credit (EITC) and Child Tax Credit (CTC) by helping taxpayers file accurately and claim everything they're entitled to.
3. Increase tax participation by making our product easy to use for taxpayers with a variety of physical and cognitive abilities, aptitudes, attitudes, and access needs.
4. Empower taxpayers who start a tax return to successfully file their return by giving them help along their filing journey, including access to live customer support chat with humans, not bots.

Design principles

During early formative research, we heard from taxpayers about the many, intertwined burdens of tax filing:

• Cost (~ $160 a year) would increase what they owe/reduce what they get back
• Time (~ 8 hours a year doing their taxes)
• Psychological burden / anxiety that they won’t maximize their return or even get in trouble

These burdens essentially mean that there’s a tax on doing your taxes.

This is how we design to earn trust, build confidence, and reduce anxiety.

✓ Help taxpayers file accurately.

We hold ourselves to the highest standards to generate accurate tax returns for taxpayers. But filing accurately isn't always about putting the most technically accurate, lawyer-approved words on a screen, or giving all the details at once to cover every edge case. It doesn't matter how accurate a question is if people misunderstand it and answer incorrectly. There's no "happy path" with taxes — every single question has the potential to confuse taxpayers due to the complexity of taxes, variety of individual tax situations, and range of tax literacy.

We work closely with tax lawyers to understand the complexities of the tax rules so that we can translate them into plain language questions that taxpayers can answer without seeking outside help. And we let complex information unfold through progressive disclosure to keep taxpayers focused and to reduce confusion. If we provide every detail at every step, we risk overwhelming many to serve a few.

✓ Do the hard work to make it easy.

Understanding the tax code is hard work that the average taxpayer shouldn't need to do. Instead, we do the hard work to make it easy so that filing your taxes is a manageable task.

Direct File removes the burden from the taxpayer to understand an impossibly complex tax system and puts it on the IRS to figure out the right questions to ask, apply the rules accordingly, and tell the taxpayer what benefits they qualify for and their tax amount.

This assertion model helps taxpayers get all of the benefits they're entitled to, and also prevents mistakes due to misunderstanding eligibility rules. For example, we don’t directly ask “What’s your filing status?” because taxpayers may not be able to answer this accurately and confidently due to the jargon and complex rules around who can use which status. Instead, we ask a series of questions to narrow down the options to only the status they’re eligible for — and for each of those questions, we use plain language and clear instructions to help them answer confidently and accurately.

✓ Find ways to simplify and automate the filing process.

Gathering tax documentation and manually entering information from tax forms increases the time and psychological burden of filing taxes. The burden of manual input is even heavier on those who use assistive tech.

We can alleviate these pain points by gathering tax return data from IRS systems, filling this information on a tax return and allowing the taxpayer to review and make edits. For example, we can:

• Fill in biographical information already provided to the IRS via the ID.me verification process to speed up the filing process (e.g., name, date of birth, contact info).
• Import IRS security features so taxpayers don't have to hunt for this information on other websites (e.g., Identity Protection PIN, Social Security number, last year's AGI).
• Offer taxpayers the option to import tax forms the IRS already has on file for them (e.g., Form W-2, 1099-INT) or link them to existing forms in their Online Account (e.g., Form 1095-A).
• Reduce errors and rejections due to manual data entry.
• Use imported data to confirm if a taxpayer’s tax situation is supported by Direct File.

In multiple research studies, taxpayers have expressed that the IRS already has their information and that they expect to see this information prefilled in their tax return.

Data import helps us meet taxpayer's expectations so they can file faster with confidence and accuracy. We also earn trust with taxpayers by being transparent about what data the IRS has on them and the original data source.

✓ Fill tax literacy gaps and empower taxpayers.

When taxpayers don't understand, they're more likely to make mistakes, face additional "time tax" to understand or fix errors, and miss out on important benefits. People who aren't required to file taxes – but may be eligible for tax benefits – are also less likely to attempt to file their taxes if the process is overly burdensome.

When tax literacy is achieved, taxpayers feel more empowered and in control because they understand how their taxes were calculated. They also feel more confident that they're doing their taxes correctly, which should translate into less anxiety and psychological burden.

Tax literacy can evolve as taxpayers experience life changes. Someone can feel knowledgeable one year and lost the next because they're dealing with new tax situations, like getting a divorce or having a baby or bringing in a new kind of income.

✓ Provide transparency.

Making something easy to use doesn’t necessarily mean hiding all the complexity. Hiding too much can increase anxiety. We aim to provide just enough transparency to help taxpayers understand what’s going on so they can feel empowered to make good decisions and understand how their taxes are calculated at a high level.

✓ Anticipate mistakes so they're hard to make and easy to fix.

Taxpayers are human and make mistakes. Design with this in mind to prevent errors and help taxpayers identify and resolve errors.

This is especially important for errors that could result in a rejected return, which would damage taxpayers’ trust in the IRS and our ability to help them file an accurate return.

✓ Taxes are the product.

Taxpayers don’t expect or want to be entertained or delighted while paying their taxes with a government-provided tax filing tool. Direct File focuses on helping taxpayers file their taxes accurately and confidently. Adding a bunch of bells and whistles would distract from that and risk losing their trust.

✓ Taxpayers are real people.

Design and content decisions should be informed by what best serves taxpayers: an incredibly diverse group with an array of circumstances. Good design is design that works for everyone.

Operating Principles

How we operate to help achieve our goals and principles.

We are collaborative.

There’s not a single problem that can be solved by one person or by one discipline area.

We design with taxpayers, not for taxpayers.

Our content and design decisions are directly informed by conversations and usability sessions we do with real taxpayers. Every research session aims to answer the question “Was the taxpayer able to accurately and confidently answer the question?”

Content is the design.

Content and design are intertwined. UX writing and plain language are key.

We exclusively design in mobile dimensions.

We design at mobile dimensions because it forces us to keep the design patterns simple, the content short, and helps stakeholders understand the constraints. Using simple patterns helps make coding easier which makes it easier to code for accessibility.

Good design is design that works for everyone.

We are 508 compliant and beyond. Direct File is designed and tested with taxpayers who have a variety of attitudes, aptitudes, abilities, and access needs.

Filing in other languages should be just as easy as in English.

Translations will be done with the same UX writing attention given to the English. Translated interfaces will be tested with native speakers.

Progress, not perfection.

Every new feature is an MVP — we constantly look for the minimal version of a solution, then build from there. The next version of Direct File is the best version of Direct File.

We use lean and sustainable processes.

We always have a short timeline so we need to be thoughtful about when to work scrappy and when to build out an elaborate process. Balance what you need now and what the future version of this team will need.

Understanding taxpayers

Remember that taxpayers are real people.

We design for different:

• Abilities, including taxpayers who have
  • Cognitive differences (e.g., dyslexia, anxiety, high stress, PTSD, memory loss)
  • Hearing loss or who lack the ability to hear
  • Vision impairment, low vision, color blindness, contrast sensitivity
  • Physical or motor disabilities
• Aptitudes, including taxpayers who
  • Understand a little or a lot about technology
  • Understand a little or a lot about taxes
  • Have non-native English language skills
  • Have different literacy levels (52% of adults in the US read below a 7th grade level)
• Attitudes, including taxpayers who
  • Have different levels of trust in digital services for carrying out personal transactions
  • Have different levels of trust in the government and government services
  • Have different perceptions of taxes and taxpaying
• Audiences, including taxpayers who
  • Have different family situations (divorced, multi-generational, mixed status, etc.)
  • Are from any cultural background
• Access needs, including taxpayers who
  • Use assistive technology (screen readers, refreshable braille displays, enlarge type, magnifiers, etc.)
  • Use different types of devices (mobile, tablet, or desktop)
  • Experience a digital divide (have limited broadband access, only have access to public devices, etc.)

Helpful reminders about taxpayers

• Taxpayers have complex lives and family situations, complicated income situations, and varying experiences.
• Motivations are varied. Some taxpayers are motivated by the refund but for others, it's resolving the obligation, "getting caught up," or fulfilling their civic duty.
• Some taxpayers are filing for the first time, some file infrequently, and others file every year.
• Most taxpayers aren't tax experts so whether it’s their first or 50th time filing taxes, there are likely to be aspects that are confusing.
• Tax discomfort is fueled by uncertainty caused by lack of general tax knowledge, new life situations, and negative experiences with past tax filing methods.
• New life situations (e.g., marriage, employment, and children) expose taxpayers to new and confusing tax topics, no matter how often they file.
• Some taxpayers may have gone through a serious life event during the tax year (e.g., a death of a spouse or child, divorce). While “regular” life events like moving, a child turning 17, or a child turning 13 may not trigger thoughts about taxes, there are tax implications that people may not be aware of until they file.
• Taxpayers’ tax comfort changes over time and is impacted by whether they trust themselves to file correctly and feel confident they know how to maximize their tax return or reduce their tax liability.
• Taxpayers go to many sources for the support they need to file with confidence (e.g., tax preparers, tax software, online searches for articles, videos, and form instructions, family members, etc.).
• Don't assume taxpayers have their tax documents when they start the task or that they able to submit their return in a single session. They might not have received their tax documents, be able to obtain them, recognize them, or have them handy or organized. These can be obstacles to filing a return.

Beyond 508 Compliance

To make Direct File available to taxpayers who use assistive technology (AT), accessibility expertise was essential to our agile development and design practices. As a result, Direct File exceeds the requirements in Section 508 of the Rehabilitation Act while also complying with the highest standards of the web content accessibility guidelines (WCAG).

The team approached accessibility from a systems perspective, so it wasn't just another to-do item on a checklist. Creating 508-compliant components and having a design system with reusable parts meant the team didn’t constantly need to worry about bugs. Once a component was 508-compliant, it would be suitable for everyone. The component would only need to be re-evaluated or updated if the team introduced a new design new pattern.

Our Approach to Accessibility
To support the team’s growth, detailed documentation was available on a wiki that everyone could access and update as we learned new information. The wiki also included links to trusted resources from the Information Resources Accessibility Program (IRAP), which is the IRS’s accessibility program office. Three team members held federally administered Trusted Tester certifications and formed an Accessibility Resource Group to coach other teams and review code changes for conformance. Finally, the team celebrated everyone’s accessibility contributions in weekly all-hands meetings, raising both awareness of accessibility work and publicly appreciating those who did the work.

The Accessibility Resource Group relied on GitHub’s Pull Request (PR) template feature to ensure accessibility. When reviewing code, each engineer saw the same prompts. For example:

• Does it work across multiple screen sizes?
• Can it run on a slow internet connection?
• Is everything accessible by a keyboard and screen magnifiers (e.g., for low-vision users) and by speech input (e.g., for those with dexterity impairments)?
• Do multiple screen readers work as expected (e.g. JAWS and VoiceOver)?

This checklist supported efficient review processes and ensured that new accessibility issues weren’t accidentally introduced. A culture of constant improvement, rather than waterfall-style lockstep development, helped to catch and address any new issues that did make it through.

Additionally, the certified Trusted Testers conducted end-to-end reviews to catch any issues missed through the PR process. As part of the Direct File development process, accessibility problems were tracked as bugs, just like any other system feature. Section 508 violations were highly prioritized, and all issues were refined with design and engineering to understand how to resolve them. Over time, fewer and fewer bugs made it through, demonstrating this effort’s success.

Flow logic: How were the questions designed and sequenced?

Introduction

The flow of Direct File was strategically designed to be assertive and dynamic.

This means we're not just digitizing fields from IRS forms and making taxpayers figure out how to fill them out. Instead, we're doing the hard work to make it easy for taxpayers. What this looks like:

• Digesting the tax code to understand exactly what we need to know and how individual pieces fit into Direct File holistically
• Designing streamlined questions so that we can assert eligibility for multiple tax benefits at the same time, while maintaining plain language and ease
• Ordering questions strategically to get as much value as possible from early questions, so that we can dynamically hide questions that aren't relevant or infer answers to later questions

How do we design the flow of questions?

Every designer does this a little differently, but this is the general process.

Step 1: Figure out what Direct File needs to know about the taxpayer, and why.

The first step is figuring out what information we need from the taxpayer to make a determination about their taxes. For example: What filing statuses are they eligible for? Do they have a dependent? Do they have any taxable Social Security income? What standard deduction amount do they qualify for? Can they claim the Earned Income Tax Credit?

To do this, we (designers) consult relevant IRS publications and partner with IRS General Counsel to understand all of the information needed and how it's used by the IRS. Some of this will be obvious from IRS publications, and some of it will require engaging with General Counsel to understand exactly what information is needed and how it's used.

At the same time, we work with engineers to understand the information needed for Modernized e-File (MeF) and PDF (the downloadable federal tax return as PDF) purposes. This research is typically done by our engineering partners. Sometimes, the MeF and PDF information requirements will match what we've learned from IRS publications. Other times, there will be requirements related to MeF and PDF that aren't covered in IRS publications. This is why it's important to consult all sources from the beginning. This step also involves researching any constraints on the information imposed by the MeF schema.

When this is done, we'll have a comprehensive list of the information that Direct File needs. In the next step, we'll come up with a strategy for how to get it.

Step 2: Synthesize the information to understand how it fits in to the larger Direct File flow.

Once we understand what information we need to collect and why, we synthesize this information to figure out:

• Do we already ask for this information in Direct File?
• Can we derive this information based on other questions we ask?
• Can we expand or adjust any existing questions to incorporate this information?

We go through this exercise first to exhaust all other options before adding a new question. To do this, the designer needs to understand why the information is needed and how it relates to other parts of the product. This helps us identify opportunities to merge like questions or tweak existing questions to meet the need. The best case scenario is that we can use an existing question and save the taxpayer the burden of answering extra questions. The next best case is that we can tweak an existing question to get the information we need.

If we determine that we need to add a new question, then we think about how to integrate it into the flow. We ask ourselves:

• What new questions might we need to ask?
• Are they similar to other questions in Direct File and should we consider grouping them to make them easier for taxpayers to answer?
• Are the answers to these questions needed for other tax scope, particularly tax scope that's actively being worked on or coming soon to Direct File?
• How might this affect other areas of Direct File?

When this is done, we'll have a list of the new information we need to collect from the taxpayer and an initial strategy for how to collect it.

Step 3: Determine the most efficient and HUMAN way to structure the flow.

Next, we determine where to integrate the new questions into the flow.

It's important to ask questions efficiently, but it's not all about efficiency. We're aiming for a balance of efficiency and humanity. Sometimes we need to add an extra question to make a subsequent question easier to answer, and that's okay.

Figuring out the order of questions is little bit of an art and a little bit of science. We don't have rigid rules, but we have these general guidelines:

1. Front-load knockout questions so that taxpayers with out-of-scope tax situations are informed as early as is practical.
2. Front-load questions that serve multiple tax purposes. Asking these early in the flow helps Direct File know if a taxpayer is disqualified from certain benefits so that it can stop asking unnecessary questions. For example, the questions about the taxpayer's relationship to a family or household member are heavy hitter questions because so many tax benefits have a "relationship test." These questions give Direct File early intel about which benefits the taxpayer is disqualified for based on failing the relationship test. This allows Direct File to filter out any downstream questions related to those benefits.
3. Place questions later in the flow if they're only used to inform one or two edge case determinations. For example, there's a special rule for people who made under a certain amount of money while they were full-time students and/or physically or mentally unable to care for themselves. The rule allows them to be treated as having a higher earned income to calculate their Child and Dependent Care Credit and dependent care benefits exclusion. To figure out if this rule applies to the taxpayer, Direct File asks: "In any of the months when you were <a full-time student/physically or mentally unable to care for yourself/a full-time student or physically or mentally unable to care for yourself>, did you make <$250/$500> or less?" Even though this relates to questions earlier in the flow (about their status as a student, their ability to care for themselves, and their income), we decided to ask this as late in the flow as possible in the Credits section. This allowed Direct File to collect more information about the taxpayer that could potentially filter out this question. For example, we set up this question so the taxpayer wouldn't see it unless they were a full-time student and/or unable to care for themselves, met the requirements to qualify for the Child and Dependent Care Credit, were Married Filing Jointly, had earned income under a certain amount, and had qualified child and dependent care expenses that were greater than the earned income of the lowest earning taxpayer. This gives the taxpayer more opportunities to have this question filtered out for them, and the chance increases the later the question appears in the flow.
4. For complex or dense questions, consider adding a gating question that's easier to answer, even if it's less efficient.
5. Group similar questions to make them easier for taxpayers to answer, even if this means you need to deviate from the other general guidelines. You may have questions that fall nicely into existing themes, like citizenship or life circumstances or income. It usually makes sense to group these questions together (but not always). Grouping similar questions prevents the taxpayer from having to context switch and answer similar questions scattered across different sections.
6. Front-load questions that are easier to answer before asking the harder ones. For example, answering a question about how long someone lived with you is easier than answering a question about the cost of keeping up your home or the share of someone's living expenses you paid. Asking these early on can help disqualify the taxpayer from certain benefits and save them from grappling with the harder questions.
7. For harder or more sensitive questions, don't ask them until you know you need them, even if that means separating similar questions into different parts of the flow. For example, when adding a family or household member, Direct File asks for information about the family member's TIN to help establish if they're a dependent or qualifying person for tax benefits, but doesn't ask for the actual TIN until later in the flow once we know the family member qualifies.
8. Ask eligibility questions before calculation questions. For example, ask questions to establish if the taxpayer qualifies for the Child and Dependent Care Credit before asking questions to calculate the amount of the credit.This allows us to tell the taxpayer as soon as possible once they qualify for a benefit and explain why they're about to see a slew of extra questions.

How do we document the logic behind the flow?

As you can tell, designing the flow requires a deep understanding of the questions in Direct File, why we ask them (including all of the detailed tax nuances), and how they relate to other questions in the flow.

So how do we keep this straight?

We have a system for documenting this logic in our design tools (Mural or Figma). It consists of "Informs" tables, arrows and "clippies", and "Who sees this" banners.

"Informs" tables

There's an "Informs" table next to almost every question screen in Direct File that outlines why each question is being asked. This helps us keep track of why we're asking the question and what we need to be able to extract from the responses.

Arrows and "clippies"

The screens are connected by arrows that lead the taxpayer down different paths depending on how they answer. These arrows are often annotated with a green "clippy" icon, which we use to indicate when Direct File knows enough about the taxpayer's tax situation to be able to assert something, even if it's simply asserting that the child they're adding to their tax return can't be their qualifying child dependent.

"Who sees this" banners

Direct File dynamically filters questions to only ask those questions that are potentially relevant to a given taxpayer. A relevant question is one that could result in a change to what is entered on a form or schedule of the tax return. For example, Direct File might ask a question to establish eligibility to claim a tax credit, but if the taxpayer is already ineligible for the credit due to another reason, the question will not be asked. Where this is relevant, you'll see an orange banner above the screen that specifies who will (or will not) see that screen.

Data Import system

For the 2024 tax season, Direct File explored ways to simplify and automate the filing process.

Taxpayer benefits of data import include:

• Faster to complete return
• Reduce human error due to typos
• Alleviate burden of manual input for taxpayers who use assistive tech
• Increase accuracy of information submitted
• Reduce rejections when the taxpayer submits

Data sources we leveraged data from:

System	Details	Data imported to Direct File
ID.me	IAL2 verification source taxpayers use to sign up for Direct File and log in	Biographical information and contact information
IP PIN Service	An identity protection PIN (IP PIN) is a six-digit number that prevents someone else from filing a tax return using your Social Security number (SSN) or individual taxpayer identification number (ITIN).	IP PIN
REDACTED	REDACTED	Forms W-2, 1099-INT
REDACTED	REDACTED	Forms 1095-A, Last year's AGI

For the first pilot year (TY23) of data import we only imported data for the primary taxpayer.

To use Direct File, the primary taxpayer was logged into ID.me and authenticated so we could import their data securely. Spouse and dependent information was not imported because we didn't build a mechanism for the spouse or dependent to consent to their data being imported to someone else's tax return. Without consent, there's a privacy and security risk. See “The future of data import” for details on how we can expand data import capabilities.

Data Import Design principles

The data import design team used the Core Direct File design principles as a starting point to design data import experiences. As we refined our design concepts, spoke with taxpayers and got user insights, we refined design principles around data import user needs and expectations.

✓ Reduce time and psychological burden.

Gathering tax documents and manually entering tax information is tedious and puts burden on the taxpayer. The burden of manual input is even heavier on those who use assistive tech.

If the IRS already has this information available, we should prefill as much tax information as we can to taxpayer's federal tax return. Since a lot of forms are inaccessible, data import can bring more equity to the tax filing process for assistive tech users.

✓ Give taxpayers control of their data

Give taxpayers the choice to use their own data or manually enter tax form information instead. If they do decide to import data, they should be able to review and make edits if necessary.

✓ Provide transparency.

Inform taxpayers about what data the IRS has on them, the data source and how the imported data will be used on their federal tax return.

✓ Help taxpayers fix issues with their data.

This goes hand in hand with data transparency. We inform taxpayers where their data is coming from so if there's an issue, they know what to do. For example, if their name is out of date because they got married, they can contact ID.me to update their name. If their W-2 shows incorrect information, they should contact their employer who issues the W-2 to get it corrected and resubmit a correct W-2 to the Social Security Administration which sends it to the IRS.

✓ Build trust.

Taxpayers already think the IRS has all their information based on previously submitted tax returns. Deliver on their expectations and make it easier for taxpayers to confidently and accurately file their taxes.

✓ Reduce errors and rejections.

By importing data we can reduce the likelihood of human errors related to data entry before submission. This has a downstream positive impact by reducing the number of common rejections post-submission, e.g., IP PINs, employer identification numbers, etc.

✓ Progressive disclosure.

Reveal tax return data we have available to import and ask for missing data step-by-step. We don't want to overwhelm taxpayers with reviewing all their information all at once. When we ask them if they'd like to import information, we provide the most important details first so they understand what they will be imported. For example, in the case of a W-2, we only display the employer name, employer identification number and wages. After they import, we ask for W-2 information we don't have on file for them and THEN we allow them to review all the data for their W-2.

Content considerations for Data Import

✓ Distinguish between "the IRS" and "Direct File"

When explaining how data import works or where data comes from, clearly distinguish between "the IRS" and "Direct File" so that taxpayers understand that data is coming from IRS systems of record. This increases trust in the data. Additionally, Direct File is a tax preparation tool, not a data source.

• *Example snack:

• *Example breather screen, explaining what Direct File can do and where data comes from: *

  

✓ Always explain where imported data comes from

Always describe where we get data from to increase trust in Direct File, provide transparency, and give clarity in the event that the data looks incorrect.

• Example snack: We told the taxpayer that their biographical data came from ID.me rather than another IRS system of record. Since people move or can change names, explaining that the information was pulled from ID.me and not the IRS may alleviate fears that IRS has incorrect information.

✓ Use the right terminology to describe how data import works

Taxpayers had different perceptions of how data import would work. Use descriptive, plain language terminology when writing about data import functionality in Direct File. Select the appropriate term to use, depending on the context or flow. We used the terms like "import" and "fill in" to describe how Direct File can add tax forms or biographical information to a tax return. In a few cases, we used the term "pre-fill" when another term wasn't possible. Avoid over using "pre-fill". We don't want to give the impression that Direct File is filling out an entire tax return, and fill in or import work as substitutes. We also avoided using the word "pre-population" in favor of other plain language terms.

Also avoid terms like "upload" that indicate that a taxpayer has to upload their tax forms to Direct File or connect to a third-party source.

UX system for Data Import

Data types

• Biographical information that is mostly evergreen unless there are life changes
  • Name
  • Date of birth
• Contact information that can change and IRS needs to confirm this is still accurate
  • Mailing address
  • Phone number
  • Email
• IRS security features
  • Identity Protection PIN (IP PIN)
  • Social security number (SSN)
• Tax return information
  • W-2s for jobs
  • 1099-INTs for interest income
  • 1095A for marketplace health insurance (which impacts eligibility for the Premium Tax Credit)

UX patterns for presenting imported data

The patterns are listed from small to large based on complexity and the level of effort to design and implement.

1. Import a value on a single screen

For this pattern we leveraged existing screens from the tax flow and created a new variation for data import which filled in information for a single data value.

Scenario 1.1: Single screen

For some screens, the data import version replaced the existing screen where we asked taxpayers to enter information. This was a one-to-one screen replacement in the tax flow.

Design notes:

• Content updates were made to encourage the taxpayer to review the prefilled information instead of entering information or answering a question.
• When we pre-filled an input we removed "(Required)" from the input label since the taxpayer didn't have to do anything.
• We made these inputs fields uneditable because the information is specific to the taxpayer and considered evergreen.

Scenario 1.2: Condense multiple screens into one screen

For some task flows, there was an opportunity to reduce the number of screens and allow taxpayers to move through the tax return more quickly. In the case of IP PINs, we were previously asking taxpayers:

1. Do you have an IP PIN?
2. If yes, are you ready to enter it?
3. If yes, what is it?

If Direct File detected that the taxpayer had an IP PIN, we could replace screens 1-3 with a new screen that prefilled the information for the taxpayer.

2. Hide screen, don't show anything

If Direct File looked for a taxpayer's IP PIN and didn't find one, we hide the IP PIN screens. No need to ask or display anything.

3. Conditional assertion screens

This is the MVP approach to letting taxpayers know the IRS detects they have a specific form in their Individual Online Account in lieu of importing the tax form information to their federal tax return.

In an ideal world, we would have imported the data from Form 1095-A into a taxpayer’s return but we launched this form towards the end of filing season on April 3, 2025 which gave us very little time to design, implement and test.

4. Info alerts

This is related to "Conditional assertion screens". In addition to displaying these screens, we also displayed info alerts on relevant screens to help taxpayers accurately answer questions related to Form 1095-A. The alerts informed taxpayers that Direct File detected Form 1095-A in their Individual Online Account.

5. Mini data view

The mini data view leverages the UX for our regular data views which aggregates a taxpayer’s responses in a subsection in order for them to review the information before moving onto the next subsection.

When a taxpayer starts their tax return, we show them a “mini data view” which combine several pieces of information, basic information about them and their contact information, so they can review and make edits. After the taxpayer makes an edit, they are taken back to the mini data view until they hit Continue which takes them to the rest of the questions in the About you flow.

6. Imported tax form data in subsections

The holy grail of the data import experience was redesigning an entire subsection through the lens of data import. This was the highest lift in terms of design and engineering effort because:

• tax logic was involved
• we needed to determine the conditional logic of what screens we show and hide
• navigation was tricky, especially when considering what would happen if the taxpayer exits in the middle of importing data
• we needed to have a backup UX plan in case the data import service was down

We designed data import flows for the Jobs (Form W-2s) and Interest income (Form 1099-INT) sections where we:

1. Inform taxpayers we have data available to import (W-2s, 1099-INTs)
2. Give taxpayers the choice to import all, some or none of the data
3. Ask taxpayers to fill in missing information
4. Prompt taxpayers to review each form they imported via a data view
5. Take taxpayers back to the collection hub so they can manually add additional forms we didn't have available to import or their spouse's information if MFJ

The full data import experience involved the following actions and decisions from the taxpayer:

• Import
• Review
• Edit
• Add missing information
• Don't import

7. Imported tax forms with knockouts

With the ability to import data from W-2s and 1099-INTs was the possibility of importing a W-2 that contains a knockout because the taxpayer's income isn't supported by Direct File.

To address this scenario we created a knockout screen that would show after the taxpayer imported either their W-2 or 1099-INT. The knockout screen can display either a single or multiple reasons explaining why Direct File doesn't support their tax situation.

We used preexisting content for knockouts to display in the accordions and we leveraged the knockout banner at the top which would display in all subsequent screens. If the taxpayer thinks the knockout is a mistake or they want to learn more, they can review their imported forms and make edits as well as remove the imported item and manually re-add it. If the taxpayer manually inputs the same W-2 or 1099-INT information, the existing knockout screens in the flow informs the taxpayer they are ineligible to use Direct File.

Backup strategy

We made sure to have a backup UX plan in case the data import service was down. We opted to default to the existing flows and screens where we ask taxpayers to input all their information.

Data Import Design challenges

Upfront challenges we knew of

• Timeliness of forms: Forms are required to be submitted to the IRS at different times which means all of the taxpayers tax information isn't available until the very end of the filing season. If a taxpayer prepares their taxes in early February, they won't have the ability to import all of their data vs if they filed later in April.
  • UX result:We fragmented incorporating data import into the tax return section by section which aligned with our roll out plan.
  • We can't import spouse's data: This is frustrating for taxpayers who have recently filed Married Filing Jointly and know the IRS already has their spouse's information.
  • UX result: We used a breather upfront to create more progressive disclosure, separating TP1's forms from TP2's forms, as well as more progressive disclosure after TP1's forms had been imported.
    • We added data-import-breather-spouse ("First, we'll check if we can fill in some of <TP1FirstName>'s Form W-2 information.") and jobs-data-import-breather-done ("You're done reviewing all of the Form W-2 information that was imported for <TP1FirstName>. If you have more W-2s to report <for TP1FirstName or SpouseFirstName>, you can manually add them next.")
    • We used TP1's first name rather than just "you," to further clarify that we weren't referring to the plural "you"
    • We made the snack "Why do I have to manually add my spouse's W-2 information?" more prominent.
    • Future state idea: Revisit the flow/collection hub for adding MFJ W2s and other income types
• Tax flows are complex: We couldn't just build an entirely new UX framework and system in the amount of time we had as a small team. This meant that for year one of data import, we would retrofit what a data import experience looks like using the existing design framework as the foundation and would "data-importify" screen by screen, section by section.

Assumptions going into the first phases of data import design

• Complete information: We thought the IRS had all of the Form W-2 and 1099-INT information available to import.
  • Reality: The IRS only receives some box 12 codes, does not receive box 14 codes or state tax information
  • UX result: We had to add additional screens to the flow asking taxpayers to review their forms and add missing information. In an ideal world, the taxpayer should only take two actions: import and review.
• Timeliness of 1099-INTs: We thought the IRS would have received a majority of 1099-INTs before tax day
  • Reality: the average day that the IRS received 1099-INTs from payers is April 13.
  • UX result: 1099-INTs (and other forms) may need a different UX treatment than W2 to help set TP's expectations, if 1099-INT were to launch on Day 1 of Direct File next tax year.

What we learned along the way

• Fetching data:We decided to fetch the data once to simplify + add UX implications of not having the latest data.
• Handling of corrected W-2s: We simplified by only supporting standard W-2s.
• UX result: Strip out unsupported characters (commas, periods) for required fields. If the taxpayer edits the information, the existing error system will alert them that they can't add unsupported characters.
• Review mechanism: Taxpayers want the flexibility to review as much or as little as they want. In usability sessions we saw participants take different approaches to review imported data. Some were diligent and took the time to review the imported information line item by line item while others quickly scanned the information because they felt the IRS was the ultimate authority and had accurate data, no need to check.

The future of data import

In March 2025, the Direct File design team brainstormed initial ideas of what a data import-first experience could look like if we could do it again.

We came up with the following expansion opportunities for data import:

• Give taxpayers direct control over how they use imported data on their tax return
• Error prevention and recovery to help taxpayers answer questions accurately through data import
• An improved "Getting started with Direct File" module to inform taxpayers if Direct File supports their tax situation
• Improved Income IA and builder experience to provide taxpayers with an efficient path that will show only show them relevant and necessary sections in order to complete an accurate tax return
• An interactive screener experience to help taxpayers assess if Direct File is a fit for their tax situation before committing to completing the id.me/registration/login task.

Paper Filing Path

This is how Direct File supports the need for paper filing. There are two scenarios in Direct File where a taxpayer will need to paper vs. e-file their federal tax return:

1. A TP and/or their spouse/dependent(s) indicated they have an IP PIN but they cannot retrieve it.
2. A TP and/or their spouse reported that they filed a federal tax return the previous year but cannot find their prior year AGI or Self-select PIN (SS PIN) to confirm their identity.

Paper path: missing IP PIN

Where DF asks about IP PIN

The TP reports if they and their spouse/dependents, if applicable, have an IP PIN in the following sections:

• Primary TP: About you section
• Spouse: Spouse section
• Dependent(s): Family and household section

Once the TP indicates that any individual on their return has an IP PIN they can't retrieve, they receive an alert and view a breather screen to flag that they will be required to paper file their return. They are also provided with guidance on steps to take to retrieve an IP Pin so they can e-file their return instead.

Dynamic checklist subsection

When the paper path is triggered by a missing IP PIN (checklist version A, below) the last subsection in the 'Complete' section updates from 'Sign and submit' or 'Sign' then 'Submit' to 'Print and mail'.

Print and mail section

The 'print and mail' section then provides the TP with:

• An alert reminding them they can e-file if they add any missing IP PINs
• Step-by-step instructions on how to file a paper return.

Paper path: missing SS PIN or AGI

Where DF asks about SS PIN and AGI

The TP reports if they and/or their spouse filed a return last year but are unable to find their prior year SS PIN or AGI in the 'Complete' section of Direct File.

Note: If ESSAR is working the primary TP should never have to report their prior year SS PIN or AGI because their identity is already verified via ID.me. If ESSAR is down, then the primary TP will be required to use their prior year AGI or SS PIN to confirm their identity if they filed a federal tax return the previous year.

Once the TP selects that they or a spouse cannot find their prior year SS PIN or AGI, they receive an alert and view a breather screen to flag that they will be required to paper file their return. They are also provided with guidance on steps to take to retrieve their SS PIN or AGI so they can e-file their return instead.

Dynamic checklist subsection

When the paper path is triggered by a missing IP PIN (checklist version D, below) the last subsection in the 'Complete' section updates from 'Sign' then 'Submit' to 'Print and mail'.

Print and mail section

The 'print and mail' section then provides the TP with:

• An alert reminding them they can e-file if they add any missing IP PINs
• Step-by-step instructions on how to file a paper return.

Rejections design guidelines

A federal tax return can be rejected for one of many (hundreds) of rejection reasons. For the most frequently occurring rejection codes, we deliver an experience that guides taxpayers through the rejection resolution process. There are two parts to this:

• Rejection message that is accessible from the dashboard. This message includes a plain-language description of the error and brief instructions for resolving it
  • If there are multiple errors on the return, these reasons appear in an accordion
• Alerts that appear throughout the flow explaining what the taxpayer needs to do on each screen

If we do not have an-app rejection explanation for a code, we just display the code and instructions to contact Customer Support.

Update Process

Before filing season, each team should review rejection messages that relate to their part of their product and determine if anything in the flow has changed, such that we need to change our instructions for how to resolve the rejection.

The Data Insights team should review the most common rejection codes from the previous filing season and note any that are not already included in our library of rejection resolution flows. Product teams should partner with Customer Support on creating new flows and use Knowledge Article content as a resource.

Any changes will need to be reviewed by Counsel.

Direct File Email Messaging

There are nine emails that Direct File may send out to a taxpayer. Each email has an English and Spanish version. We determine which version to send based on the taxpayer's selection on comms-different-language-choice.

Email style guide

"From" address

• Emails are sent from "no-reply-direct-file@irs.gov"
• The address shows as "Direct File no-reply"

Buttons & CTAs

• Use only 1 button per email to focus the user's attention
• Keep links and calls-to-action limited to 1-2 per email to focus attention and action
• Say "Sign in to Direct File" when directing users to the product

Subheadings & bold

• Use subheadings to label different sections of the email
• use bold to call out important information or keywords for scannability

Tone, etc.

• Refer to DF product style guide

Privacy

Counsel has strong concerns about sharing information in these emails, including fact of filing (the fact that a taxpayer has submitted a tax return). We received approval in January of 2024 to create a RAFT (Risk Acceptance Form and Tool) where we acknowledge the risk involved in sending emails that acknowledge the fact of filing and return status.

In the future, we should explore the feasibility of further customizing emails to reflect:

• Whether the taxpayer is owed a refund or has a balance due
• Whether the taxpayer has a state filing requirement

Future improvements

• Refine the email preview text
• Test emails for accessibility

Email Measurement

Metrics tracked:

• Open rate - opens / delivered
• Click rate - clicks / delivered
• Click-to-open-rate - clicks / opens
• Bounce rate - bounces/ sent
• Page path after clicking in email

Deliverability - something to focus on next year. Delivery = the email didn't bounce. But, deliverability means that the email got in the Inbox - and not spam etc. - (https://sendgrid.com/en-us/blog/email-deliverability)

Things to test: a/b test subject lines to see if we can increase opens/clicks based on certain wording

Editorial process for creating emails

All emails from the previous tax year should be reviewed and updated for the upcoming tax year by late fall. New and updated content needs product review, counsel review, and translations.

1. Review emails from previous season, looking for content that needs to be changed due to new scope, timing, or audience. The raw text of the emails should be stored in HTML.
2. Make required edits in Figma.
3. Send edits to Direct File leadership for strategic review.
4. Send edits through editorial review.
5. Send edits through Counsel review.
6. Get content translated.
7. Make edits to the emails in HTML.
8. Work with engineering to schedule send of batched end-of-season emails.

Regular season emails

Return Submitted

This email is sent every time a taxpayers submits a return through Direct File. It communicates:

• What to expect next
• Reminder to file state taxes if required
• Instructions to get help

Return Accepted

This email is sent when a taxpayer's return is accepted. It communicates:

• What to expect if owed a refund
• What do do if you have a balance due
• Information and services available on Direct File
• Reminder to file state taxes if required
• Instructions to get help

Return Rejected

This email is sent if a taxpayer's return is rejected. It communicates: It tells the taxpayer to sign in to fix their return and resubmit. It also gives information about filing for an extension and reminds them to file state taxes if they need to.

• The need to sign in to review the rejected return
• Information about deadlines
• Information about filing for an extension
• Reminder to file state taxes if required
• Instructions to get help

Error Emails

Pre-Submission Error

This email is sent if a user clicks the submit button but there's a problem, and they receive an error and the return doesn't get sent to MEF. If the user doesn't successfully submit within 1 hour, this email will get sent to them to nudge them to contact support and keep them in the loop with Direct File.

This email communicates:

• There was a technical issue and the return was not submitted
• Their tax return information is saved
• DF is working to fix the issue
• TP needs to reach out to customer support for next steps
• How to file for an extension if TP is concerned about meeting the deadline

Post-Submission Error

This email is sent if a user clicks the submit button and it seems that their return was submitted, but there's a problem and the return doesn't get sent to MEF. This is a rare occurrence.

This email communicates:

• There was a technical issue and the return was not submitted
• Their tax return information is saved
• The TP needs to find another way to file.
• Information about the deadline
• How to file for an extension if TP is concerned about meeting the deadline

Error Resolved Email

This email is sent after an error is fixed. It communicates:

• There was a technical issue and the return was not submitted
• The problem has been fixed
• Their tax return information is saved
• Information about the deadline
• How to file for an extension if TP is concerned about meeting the deadline
• Instructions to get help

End-of-Season Emails

Reminder to submit state

This email is sent to all TPs who have submitted a federal return through Direct File and who live in a state that has a state tax filing obligation. For the TY24 filing season, it was sent on April 4. This email communicates:

• TP can sign into DF to be directed to their state filing tool
• TP may be able to transfer data from their federal return to their state return.

Reminder to Submit Federal

This email is sent to all TPs who started a return in DF but have not yet submitted it by early April. For the TY24 filing season, it was sent on April 4. This email communicates:

• Expanded scope that has been added during the filing season
• Information about the deadline
• Information about filing for an extension
• Instructions to get help

Reminder to Resubmit Rejected Return

This email is sent to all TPs who had their return rejected in DF but have not yet resubmitted by early April. For the TY24 filing season, it was sent on April 4. This email communicates:

• The need to sign in to review the rejected return
• Information about deadlines
• Information about filing for an extension
• Reminder to file state taxes if required
• Instructions to get help

Looking Ahead: Future Design Problems to Prioritize

Future Improvements to The Direct File Screener (eligibility checker)

The Direct File eligibility checker is accessible from the public direct file landing page. As a prospective user of Direct File, I need to quickly and easily assess if Direct File is a fit for my tax situation so I can decide if I want to commit even more effort to completing the ID.me/registration/login task to file my taxes.

Current pain points (TY23)

• Taxpayers get to the end of Direct File before realizing that DF doesn't support XYZ Form or situation (e.g.: "Where do I enter my 1099-DIV? Where do I enter my mortgage interest/ property tax? Where do I enter 1099-NEC?)
• Taxpayers may submit Direct File without ever knowing they weren't eligible to, because the reason they were ineligible wasn't associated with a question or section in the checklist (e.g.: We didn't include IRA contributions as a KO last year. When we added it in, it became one of our most frequent KOs).

Hypotheses

• Our new screener experience should create a healthy point of friction for taxpayers so they understand with confidence if they are eligible for Direct File without having to complete the sign up process or file their tax return and being unpleasantly surprised by a KO.
• By making both the pre-login and post-login experiences a little more interactive, we can more successfully drive ineligible TPs to other tools.
  • The pre-login experience should feel lite and easy and provide a quick preview of what to expect in DF, but it should not feel like you're starting your taxes
  • The post-login experience should import some of your taxpayer data upfront, if available to successfully knock you out before starting your taxes.
• By creating an interactive experience upfront, we can carry information throughout the remaining tax return experience, so TPs don't feel like they're entering information twice.
• We should keep the current screener list for taxpayers who want to learn more about eligibility in this format and as a backup plan in case the interactive screener is down
• If we reframe eligibility requirements and supported tax scope through the lens of a taxpayer and common terms they're familiar with (e.g., I am self-employed, I have a business, etc) we can make it easier for TPs to understand if they are eligible to use DF or should consider another tool.

Design considerations

• Will there be any changes to IRS login/identify verification that will impact the overall signup experience for Direct File? Right now we use ID.me/IAL2
• HMW provide guidance on when it makes sense for one spouse or the other to be the one who goes through the trouble of id.me based on how data import works to ease the task?
• HMW create an interactive screener experience that feels personalized and friendly yet authoritative and credible? Consider what's the right tone and voice.
• In our interactive screener, should we give taxpayers the option to respond with "I don't know"? Direct File can respond to this input by providing the TP more information on the topic they don't know about which is great but on the other hand, how confident can DF assert if the taxpayer should consider using DF or not.
• Is there an opportunity on the screener to clarify that Direct File is different from Free File products or Fillable Forms?

Design tasks

• Understand what is possible in the authenticated version of the Direct File screener from a UX and eng perspective. This will inform the unauthenticated version of the screener.
  Document what the workflow and journey looks like for taxpayers who transition from pre-login to post-login so we can identify ways to carry over data so that taxpayers don't have to answer the same questions twice, if possible. Example taxpayer flows:

  • Starts with pre-login screener and decides they want to use DF and sign up/login
  • Starts with post-login screener and decides they want to use DF

• Identify what tax scope situations/KOs are common and painful for taxpayers so we don't prompt them to go through the signup experience
  Using the data above, consider if we need to prioritize making only certain parts of the screener interactive. If yes, what would we prioritize? (e.g., most painful KOs?)

• Review research insights on screener from Fall 2023
  Flesh out both the authenticated and unauthenticated version of the screener and see where there's overlap and redundancies to minimize duplication.
  Identify new research questions and engineering questions

Future Improvements to Direct File Information Architecture (IA)

Challenge

The current Income section IA prioritizes a limited tax scope and won't scale well as we continue to expand.

In the current Income section:

• Every income tax form type gets its own subsection on the Checklist.
• All income tax form types are displayed for all TPs. (Exception is Alaska PFD—just for Alaska residents.)
• Each income type unlocks 1 at a time, and TPs have to opt out of each one they don't have.

This setup was helpful for the 1st couple years of DF, when we wanted to be extra-explicit about what income was supported. But as we keep adding scope, the list will get too long and cumbersome.

Goals

• Identify ways to make the Income IA more scalable, so that more supported tax scope ≠ more work for TPs without that scope.
• As we support more complex income types, help TPs understand how these situations affect their taxes.

Hypotheses, to thoroughly test

Aka guesses that need lots more research, thinking through, and testing.

1) DF should group income types into categories. This will make the IA more scalable AND be clearer for TPs. For example:

• Savings and investment or maybe Interest and dividends—1099-INTs and 1099-DIVs
• State payments—Unemployment, state paid benefits, Alaska PFDs

2) DF should separate the reporting of taxable payments from follow-up questions about complex tax situations. The current Income section mixes straight reporting of taxable payments with follow-up questions about complex tax situations. This can make the TP switch mental models throughout. It'll be easier logistically (for TPs and us) if we have a separation of concerns:

• A section reserved for reporting standard taxable payments that (usually) come with an income tax form, like W-2s and 1099-series forms. These will follow the collection loop pattern, and could largely be filled in through data import.
• A section for other tax situations that could affect your taxable income. This could include info on contributions and dependent care benefits. These sections require a higher burden on TPs to answer complicated questions and could use more space to explain. This will often follow up on info reported in the Income section (like from your W-2).

3) DF should only show tax forms/situations on the Checklist that are relevant to that TP. This will provide a much more streamlined experience.

4) DF should allow TPs to report income tax forms in any order. This will provide helpful flexibility to TPs.

Deeper look at hypotheses

Hypothesis # 1: DF should group income types into categories.

This will make the IA more scalable AND be clearer for TPs. For example:

• Savings and investment or maybe Interest and dividends—1099-INTs and 1099-DIVs
• State payments—Unemployment, state paid benefits, Alaska PFDs

One way to hold more income types without making the Checklist too long is to group income into categories on the Checklist. Maybe something like this:

Perhaps these categories lead to Category collection hubs, where the decision point on which form you're adding is left until later in the flow.

Many outstanding questions

• Would a Category collection hub be helpful? Confusing?
• Will engineering weep if we move the decision point for collection loops?
• What are the criteria for determining what gets grouped together? Is it based on existing organization/categorization on 1040, Schedule 1, etc? Something else?
• Is length of the Checklist actually that big of a concern?

Next step considerations

We should conduct extensive research to identify what groupings are meaningful for people with different tax situations. (And if there's enough consensus on helpful groupings for this to be a plausible option.) For example, we heard many TPs expected Social Security would go under Retirement, but not everyone gets Social Security because they turned age 65+ and retired. This feels like a great thing for a card sort or tree test.

Hypothesis # 2: DF should separate the reporting of taxable payments from follow-up questions about complex tax situations.

The current Income section mixes straight reporting of taxable payments with follow-up questions about complex tax situations. This can make the TP switch mental models throughout. It'll be easier logistically (for TPs and us) if we have a separation of concerns:

• A section reserved for reporting standard taxable payments that (usually) come with an income tax form, like W-2s and 1099-series forms. These will follow the collection loop pattern, and could largely be filled in through data import.
• A section for other tax situations that could affect your taxable income. This could include info on contributions and dependent care benefits. These sections require a higher burden on TPs to answer complicated questions and could use more space to explain. This will often follow up on info reported in the Income section (like from your W-2).

Current IA getting unwieldy

For TY 2023, all 4 income subsections were collection hubs where a TP reported income (usually through an income tax form they received). For TY 2024, we added 2 pieces of tax scope that didn't follow this exact pattern:

• Dependent care benefits—Lots of questions, and eventually a nested collection hub for dependent care providers
• HSAs—Lots of questions about contributions, and then a nested collection hub for distributions

More hypotheses on separating taxable payments from other tax situations

Income tax forms:

• Reporting income from an income tax form is relatively easy, once TPs learn this part of filing taxes.
• Once a TP has started adding income tax forms, they're in the mindset of adding these forms. And it's easiest to add them all at once.
• TPs often don't understand all the info on their forms. This gets especially obtuse when there are codes either explaining the type of distribution (like 1099-SAs and 1099-Rs) or explaining where a [potentially nontaxable] part of the payment went (like W-2, boxes 10-14).

Income situations not reported completely on an income tax form:

• Nontaxable payments for tax-advantaged situations are more confusing for TPs, because they're not as clearly reported on an income tax form. $ info is often reported on the W-2, but requires follow-up questions to make sure TPs followed certain rules.
• TPs often set-and-forget these situations and don't understand or remember the rules.
• As a result, questions about these situations are harder to answer, and TPs could accidentally run afoul of rules for the first time and get confused/overwhelmed.
• These situations require more guidance, and it'll be helpful to walk TPs through these situations with care.
• A separate spot to dive into these situations will also give DF space to better explain how W-2, boxes 10-14 work.

Rough UI ideas

A) A new section for Additional income situations

B) A new subsection for Additional income situations

C) Condense subsections to Taxable payments and Additional income situations, and introduce a new nav page for more content

Many outstanding questions

• What's the cost to hiding more from the Checklist? Would this depart too much from the hub and spoke model, where the Checklist is a valuable point of control for the user?
• Are we cutting off opportunities where other deeper levels of navigation are needed?
• Would it be harder for TPs to find things?
• Should this be a catch-all for anything income-related that doesn't have an accompanying income tax form?

Next step considerations

• Do some digging on additional income situations we don't yet support. How many are there? How complicated? How many levels deep will they need to go?
• Would Schedule C fit here? As one of the more complicated pieces of tax scope on the near-term roadmap, it'd be a great test for how well proposed IA could scale.
• Learn from CC about the current organization/ categorization of 1040, Schedule 1, etc. Where should we mirror this setup, and where should we deviate?
• Any new structure ideas should be thoroughly tested. Is this hypothesis even true that separating taxable payments and additional income situations will be easier for TPs (and us)?

Hypothesis # 3: DF should only show tax forms/situations on the Checklist that are relevant to that TP.

This will provide a much more streamlined experience.

Another way to hold more income types without making the Checklist too long is to customize the Checklist based on the types of income a TP has. This could involve:

• Having the TP build their Income section
• Integration with data import, so we sometimes already know they have an income type

For taxable payments, this would give TPs 1 place to opt in/out of all the income types. And an easy place to change their settings, if they need to add or remove an income type.

For additional income situations, this would help us first identify if TPs have certain types of accounts. And then drill into more questions accordingly. Of note, there's multiple ways we could find out a TP has an account (like HSA, 401k, etc) with reportable activity:

• Most common: we find out in the taxable payments section, because:
  • They've already reported any distributions from their account (1099-SA, 1099-R, etc).
  • They've already reported they had employer contributions on their W-2, in box 12. (Contributions through an employer are by far the most common type of contributions.)
• Less common: we still need to ask questions to determine if:
  • They need to report contributions not through an employer.
  • They need to report on prior year contribution situations. This is extra tricky, because we learned TPs often don't realize they need to do this, and may not know to opt into questions for an account that is no longer active. So we'd need to provide extra guidance with an opt-into-this-subsection model.

This could also allow us to mention account types that don't require reporting, like FSAs.

Could be paired with "Getting started with Direct File" module

In addition to the Income builder, the team is mulling a "Getting started with Direct File" module that would front-load KOs for different types of income, and could leverage expanding data import capabilities.

Read more on the "Getting started with Direct File" module

Next step considerations

We'd need to test any UI updates thoroughly.

• How well do TPs understand this setup?
• How easily can they go back and update their answers?
• Is this customization of the Checklist helpful?

Hypothesis # 4: DF should allow TPs to report income tax forms in any order.

This will provide helpful flexibility to TPs.

At the moment, a TP currently has to go through each subsection on the Checklist to unlock the next section. Because of this setup, DF semi-forces TPs to add income types in a particular order. (This order isn't absolute: a TP could say they don't have an income type/are done adding that type of income to unlock the next subsection, and then go back and add more income later. Plus DF currently allows you to continue up until a certain point with incomplete info for an income type.)

This forced order probably isn't needed. (Social Security benefits is sort-of an exception: the calculation of taxable SS is dependent on your other income.) And it would probably be nice if TPs could enter their income in any order they choose.

Rough UI ideas

The Checklist already has an established pattern—that you have to unlock subsections one at a time. We don't love the idea of giving the Income section unique behavior on the Checklist.

What if the new nav page (listed above, for hypothesis 2) helped us with this?

[future-ia-image_11.png]

What if the behavior rules were different on this screen, and this distinction is how you decide if something lives on the Checklist or here? For example:

• All these are available at once. You don't have to unlock them 1 at a time.
• None of these are required. Though maybe you get a light warning/may-be-an-error flag if any of them are blank. Since you already told us you had them.
• (With those rules, credits wouldn't use a nav screen like this, because the subsections aren't optional, and the order matters.)

Another potential opportunity with a new nav page like this: it could give us more room to include more info. Like # of forms ready to import, or # of forms already added.

Next step considerations

Testing! Would this setup be useful? Solve a problem for TPs?

A small tangent: why "other tax situations" is hard to categorize

"Other tax situations" can affect multiple places downstream on a tax return, often depending on if you followed the rules or not. They can affect Schedules 1–3, which covers Income, Deductions, and Credits. This makes categorization murky.

Do they belong under Deductions?

Of note, there's a good argument to be made that many of these "other tax situations" like contributions to tax-advantaged accounts could go in the Deductions section, because they sometimes lead to a deduction. In fact, some of the relevant forms (like Form 8889 for HSAs) imply that the deduction amount is the most important outcome. Challenges with this categorization are:

• There are other outcomes from gathering this information. If you didn't follow the rules, you may actually owe taxes instead. Or you might learn some payments are actually taxable income after all.
• The deduction isn't always the most likely outcome. For example, with HSAs, you're eligible for a deduction if you made contributions not through an employer. While employer contributions are already noted on Form W-2, box 12. But in 2022, only 14% of HSA contributions weren't through an employer (Pub 4801). Regardless of how you made the contributions, you'll still need to answer questions to make sure you followed the HSA contribution rules.
• If a taxpayer needs to go back and edit or review an answer, they'll need to understand that this situation is/could be related to a deduction. This is putting more burden on them to understand the IRS's categorization.

What if we considered them follow-ups to Income?

This is leading us to wonder: would these "other tax situations" make more sense as follow-up questions for Income? With the idea that once DF has gathered the relevant information, it can assert more readily if a taxpayer does or doesn't qualify for a deduction or credit in those sections.

There's plenty of outstanding questions here, including: What is the criteria for determining if questions get asked in "other tax situations" vs the Deductions section (or elsewhere)? Does it rely on how many downstream places can get affected? This is a gnarly IA challenge that will be interesting to explore further.

Conclusion

These are some early ideas for future IA updates. Lots of research and further iteration is needed to determine how well these (or other ideas) would improve the overall experience and set up DF for long-term success with future tax scope expansion.

High-level next steps (detailed more above):

• Learn from CC about the current organization/ categorization of 1040, Schedule 1, etc. Where should we mirror this setup, and where should we deviate?
• LOTS of user research. What categorizations make sense to people? How many levels is too deep? How much content is too much on the Checklist?
• Do some digging on additional income situations we don't yet support. How many are there? How complicated? How many levels deep will they need to go?

Tasks

Design the experience

• Continue ideation on the interaction details of a usable builder experience.
• What is the IA structure of the to-be Income section that best fits this interaction and communicates the structure effectively to the user as they work?
• What do we do with the existing PFD question in the About you and Spouse sections?
• Address how we adequately signal to users how they can return to the control center to add/manage sections
• Address what happens to existing data if we allow them to remove whole sections
• Address rules for progression: all unlocked simultaneously, or still in sequence? Where do we enforce places where the user has to tell us they're done adding so that we know they can leave the income section for next steps? What makes sense as an interaction pattern for this that respects what we've already established?
• Explore how many levels of nav layers we feel comfortable offering for the section's navigation experience
• What are the edits and warning system impacts of these changes?
• What are the impacts on the cascade/dependencies?
• What do we do with the income-adjacent subsections and how does that fit with the builder model?
• Define how it could use information collected earlier in the experience to build the section
• Is the proposed section-builder pattern accessible

Collaboration

• Work with engineering on feasibility of different design approaches for the module and proposed use of the answers collected
• Design experiments for usability testing, discuss with Research

For Future Exploration: Adding A “Getting Started” pre-tax-prep module

Challenge

DF supports a limited number of income types, and TPs often get far into filling out their return before realizing their income situation is out of scope. This is a problem because:

• UX—It's an irritating experience for taxpayers.
• Data privacy—We don't want TPs to enter personal data into our system if they ultimately can't use it.

Of note:

• There are twice as many knockouts (KOs) in the Income section as the rest of DF.
• "Income type not supported" has consistently been the # 2 knockout TPs are encountering. (This is accessed from the Income sources subsection.)
• The eligibility checker available before you log in lists much of the relevant scope information. But TPs aren't always catching this info.
• For the pilot, we tested a more interactive version of the eligibility checker before you logged in. It didn't test well. We found that TPs expected the info they were inputting to be remembered once they logged in, and were irritated they had to re-enter info.

Goal

For the majority of taxpayers, be able to tell them if their income tax situation is in scope before they start properly filling out their return.

Idea

A module that front-loads checks for common out-of-scope forms and either KOs them before they've wasted time on the prep task or assures them they're ok to proceed and that we'll keep checking for out-of-scope situations as they work.

Where in the flow: Comes after authentication and starting a new return but before the task itself that provides the user with needed understanding of what the tax preparation experience will be like and leads to an onboarding experience that will set them up for success using DF.

Opportunity: Could we use data import to quickly identify if TPs are in scope? By front-loading income-related knockouts at the beginning?

Product hypothesis

We believe if we KO taxpayers for income scope issues at the start of the experience through a combination of imported data and manual questions, then taxpayers who are out of scope won't waste time using DF fruitlessly and will have a more efficient and accurate filing experience.

And we'll know we succeeded when more income-related KOs happen early in the experience vs. the same KOs in the Income section.

Tasks

Design the experience

• Continue ideation on the interaction details
• Examine how this idea dovetails with #15303
• Design fallbacks for missing data: design for both a data import component and direct questions to handle situations where IRS and/or the taxpayer doesn't yet have all forms for TP1 / TP2
• Define components needed and behaviors for premature exits, errors, validation
• Diagram notional design at a high level
• Define MVP

Design content

• Define rules for what checks do and do not belong in this experience (balance length of precheck experience against pain of late KO -- e.g. decide if there are rules we can use to keep it short based on likelihood of KO, etc.)
• Continue ideation on prompts appropriate for such an experience
• Explore ways of assuring the user that this isn't their only chance to answer these questions.

Define how DF will use these responses

• Define how the answers collected in this experience will be used later in Direct File, such as to pre-build sections of the Income section, and how/if we explain that up front.

Collaboration

• Work with engineering on feasibility of different design approaches for the module and proposed use of the answers collected
• Work with engineering to understand what forms we might be able to check exist for the TP
• Design experiments for usability testing, discuss with Research

Direct File Content Approval Process

How to get content reviewed and approved to launch in Direct File

Content and user research

Research does not gate publishability and is not part of the content approval workflow. However, research is critical to ensure that content is comprehensible by taxpayers, especially content that is associated with complex tax law. Research can happen at all stages of the content development process — from ideation to iteration. For instance, insights from research can be brought into conversations with tax law SMEs during the internal review stage, so that content that is being sent to CC for approval incorporates input from design, SMEs, and actual taxpayers.

DF Team SMEs

DF has a core team of tax law SMEs from IRS and Treasury who field our questions, work with us closely on tax law logic and phrasing, often do Pre-CC Reviews, and help coordinate review requests. Our core group of Team SMEs may elect to pull in additional SMEs to assist with reviews, depending on the tax topic need.

CC Reviewers

The review we call "Chief Counsel (CC) Review" is a formal review in our approval workflow. It is the final review that clears tax law-related content as legally accurate and OK for publication in DF. Tax law-related content that has not been approved by CC cannot go live in DF.

Prepping for an internal review

If you're adding something new to DF, or revising or changing something that's existing, consider running through this design checklist before you initiate an internal review.

Content & Design Checklist: How do I know that I’ve addressed everything?
A complete design may include designs for some of these elements and new content that you’ll have to draft. Check that you’ve addressed what you need to before getting an internal review.

Screen content

• Snack/bite/meals are drafted, complete with URLs for the meals

  Error messages

• Are there any new error states that you have to write custom content for?

• Do you need to write content for any in-line or field validation error messages, or can we leverage something existing?

  • i.e. if you're asking for a $ dollar amount input, and there's a legal maximum amount, you can add that information in the field validation error text.

• Does the flow you’re working on involve any tax cascade scenarios that you need to design or write content for?

  • i.e., if you change an input, does it impact your filing status, credits or deductions you are eligible for, or dependents you can claim?

• Are there any new backend system alerts that you need to write content for, or can you leverage something existing?

  • i.e., we can’t connect to a backend service like ESSAR, can’t submit to MeF, etc

  Rejections

• Are we helping to prevent top federal tax return rejections where we can?

  Navigation/IA

• If you made an IA change, did you draft new copy or revise copy so that we can represent the item on the data view screen?

• Are new questions/fields grouped into logical sub-sub-section chunks and labeled and titled on the data view?

• Are you avoiding PII (like, someone’s name) in all link and or header text you draft?

• If you added a collection item, did you define the card metadata that’s needed to represent and manage the collection?

• Does what you’re designing have any impacts to the dashboard?

• Do any questions trigger a paper path mode, and did you design the elements to support and explain it?

  Follow on work

• Are there screener impacts?

• Are there impacts to the FAQ or the landing page?

• Are there things that customer support needs to know as a result of this change (or group of changes)?

• Will this work impact anything that IRS/states communicate about DF (on their websites, comms, etc)?

Use Git lab for the content approval workflow and review steps

We created a board in GitLab to facilitate the content approval workflow process and review requests. Kick off the approval workflow for your batch of work from here.

Start by creating a workflow tracker ticket for your batch of work (unless one already exists). Important: use a workflow tracker ticket as the parent ticket for all the related review requests needed to get a given batch of content approved, because it serves as our official record of approval to use that content live in DF.

Use this issue template on your new issue: content-workflow-tracker.

That issue template ensures your ticket is labeled correctly and appears in the correct column:

The content-workflow-tracker issue template also includes instructions about next steps. Create tickets requesting the next review steps you need to get to approval for your content batch and link them to that workflow tracker ticket so it's visible when the content is ready to go live and so we are able to keep an intact record of formal approval.

Steps in Content Approval

You will need some or all of these steps for your batch of content to be considered approved:

1. Design Cohesiveness Review (details to come)
2. Editorial Review (details to come)
3. Pre-CC SME Review
4. CC Review
5. Translation Check

Do I need to do every step? What if my screens only contain xyz?

Depending on what content or changes are on the screens you're working on, you may not need to complete every single step in this workflow: use your best judgment. For example:

• If your batch of work doesn't relate to tax law at all (such as if your change is solely to navigation labels, breather screens, system errors, etc.), don't send it to Pre-CC SME review and CC Review steps, but do send it to Design Cohesiveness Review, Editorial Review, and Translation Check.
• If your batch of work involves no word changes, you can skip Editorial Review. But unless you are 100% sure there is an existing and still correct translation in place, do send it to Translation Check.

What relates to tax law?

• The underlying DF logic that determines who sees a section or a screen based on how they answered earlier questions
• Intros that describe tax concepts
• Question screens
• Rejection reasons
• Tax return alert messages that relate to tax law (you need to consider the contents of the message to know if it's unrelated to tax)
  • Related: anything that references an outcome or an explanation touching on a tax rule. Often "tax cascade" alerts and messages fall into this category.
  • Unrelated: Generic alert messages like "information missing in this section," "Warning in this section," "You can’t finish your tax return until you fix the errors in each section," and most field validation messages because they rarely refer to tax and more commonly refer to formatting instructions.
• Assertions and math screens

Design Cohesiveness Review

Create an issue for this check using the template content-workflow-cohesiveness .

This is an internal review to put another set of eyes on designs and flows to ensure they remain consistent with the DF product vision and patterns. It checks IA, taskflows, and all elements of design for consistency and overall fit. This check should not be the first time your design is reviewed for this.

Editorial Review

Create an issue for this check using the template content-workflow-editorial-check .

This is an internal review to put another set of eyes on content for consistency with the DF content style guide. If the screens contain any tax law content, they also must go through the SME and CC review processes. Editorial check alone cannot OK tax law content for inclusion in DF. For feedback on plain language content before you've reached the stage of seeking approval for inclusion in DF, make best use of weekly syncs and ad-hoc reviews with content folks on the team.

Pre-CC SME Review

This is a penultimate review, one that tells us whether or not the batch of screens is ready for one final review to hopefully be considered approved for live use in DF.

Create an issue using the template content-workflow-sme-review which includes instructions, default labels that ensure it lands in the right column, and the necessary POCs (Points of Contact) who need visibility. Pre-CC SME Review request tickets should always be linked to a parent content workflow tracker ticket so it's easy to see when a content batch is ready to be moved to the next step of the workflow.

Preparing a Review Package

In the future we may be able to fully rely on the Taxpert interface (All Screens) for our SME reviews, but until it's robust enough for our needs, we will need to prepare an annotated PDF to help reviewers understand the flow of questions and why we are asking certain questions, complete with tax law citations. Having this as a PDF is especially important to reviewers who can't access our tools.

Review packages are flexible and meant to be useful not restrictive. In general, they should include:

1. Top and bottom banners that say: "PRE-DECISIONAL | NOT FOR DISTRIBUTION"
2. A description of the item being presented and scope details that will help the reviewers understand which aspects of tax law we are intending to support with these changes and which we are not.
3. Screen visuals, including: "informs" annotations, logic arrows, tax math annotations, etc. (Screens can be Mural or Figma sketches or screenshots from the tool itself, but note it must be high enough resolution to be legible for reviewers when saved as a PDF.
4. If applicable: filled-in tax return PDFs (showing where on the form 1040 and other forms and schedules DF will be showing the output of the questions the user is filling in).
5. If applicable: manual testing scenarios and a DF POC to whom any issues found in testing can be reported.

CC Review

The vast majority of screen content in DF relates to tax law. All content that relates to tax law requires Chief Counsel's approval of tax accuracy before it can be used by TPs in Direct File. We get formal approval to go live with content via the CC Review process. It's the final accuracy check in the workflow.Before requesting CC Review, your content must be cleared for this step by our Team SMEs and must have gone through DF Design Cohesiveness and Editorial reviews, if needed. Complete those steps first.

Request a CC Review by creating an issue ticket using the template content-workflow-cc-review and link it to the parent content workflow tracker ticket so it's easy to see when a content batch is ready to be moved to the next step of the workflow.

Attach your review package to the ticket.

The SME who takes on the request will assign a turnaround date.

All feedback (or approval) will be delivered through the ticket in comments.

Likewise, deliver any updated artifacts in comments on the ticket, as well as any questions you have or related meeting requests.

Once CC approves the content, it's OK to publish in DF. But the work on it isn't done-done until that approved English content is translated and any further engineering prep is complete.

Translation Check

In order to be ready for launch, every page in Direct File must be displaying the latest approved content in both English and Spanish. Don't assume a page that already shows Spanish content is up-to-date and ready for launch. It could be old/draft content that needs re-translation.

For Spanish Glossary see Spanish Glossary Folder in Wiki folder.

For Translation Check, follow these steps

1. Carefully review every screen and associated modal (snack) in your batch using the DF All Screens view.
2. Verify every screen and modal in the batch shows the correct approved English content (CC-approved or internally-approved, as applicable).
3. If it's all showing correctly and ready for translation, ask an Engineer to update the workflow step for the content batch to "Translation Check"
4. After it's marked as "Translation check" in All Screens, create an issue in GL using the template 06_TranslationTicket for the batch and make sure to include:
   • The batch's name
   • A spreadsheet export of the English content for that batch (ask an engineer for help exporting a spreadsheet of the content for just this batch of screens and modals)
5. The translation team will take it from here, translating content and requesting Engineering to update the Spanish content in the product.
6. When Engineering is done entering the Spanish content, they will update the workflow step for the batch to "Complete." It's important to update the workflow steps and batches because this is how we will know when all screens are ready for launch.

Content Batch workflow

We have far more screens in DF now than the first year and more people working on the same screens at the same time, too. Our goal is to have awareness of where this activity is taking place and ultimately to be able to know with certainty if a screen in DF is publishable or not. We devised the batch system to handle these two needs.

Batches usher screens through a workflow to reach a state where they're publishable. "Publishable" means the screen in DF is fully updated with approved content in both English and Spanish: it could go live. Note that "publishable" doesn't mean "final"—we expect to iterate continually up to and during tax season.

A "content batch" is just a grouping of convenience. It's a vehicle for taking one or more screens through the steps of our workflow to reach a publishable state. You 'put a screen in a batch' by including any of its elements in a batch.

The lifecycle of a batch

Batch workflow steps

Over its life, a batch follows a sequential workflow. The workflow step is about what's actually been implemented on the screens in DF.

• If you have CC-approved content for screens in Mural or Figma but not yet implemented in DF, then the batch isn't yet ready to move to the next step.
• Are all the screens and modals in a batch displaying approved English and you have no more big changes queued up? Then it's time to put the batch in the Translation check step.

Certain workflow steps may be skipped (for example, you may skip from WIP to Translation check if needed), but the idea is to progress the batch of screens from step to step until it's fully updated with approved English and Spanish content, then complete and close it.

Step 1: WIP

Work in progress (WIP) is the default step when opening a batch. This is the step in which building is happening, putting screens in the batch, iterating, and experimenting. When a batch is set to WIP, its screens are all labeled as unpublishable, even if you haven't actually made a change to them yet. The assumption is that if you included a screen in your batch, it's with the intention of working on it. If you have no intention of working on a screen, you can leave it out of your batch entirely. If you later learn you want to include it, you can add it while in WIP.

Step 2: DF Review

Recording this workflow step on the batch is optional, but doing these reviews for the screens in a batch is required. DF reviews are checks we do for design cohesiveness, editorial consistency, and early checks for tax accuracy. This year we tended to do these reviews in Mural or Figma before screens were even built (which removed the need for this workflow step in most cases), but for other reviews, we really did use the DF screens themselves. Its intended use: when a batch of screens in DF is ready for the cohesiveness, editorial, or team SME reviews, you can update its workflow step to DF Review to temporarily lock screens to changes and signal to reviewers which screens are ready for their review.

Step 3: CC Review

Recording this workflow step on the batch is optional, but doing this review for the screens in a batch is required if they contain CC-owned content. CC review is the formal Chief Counsel review for tax accuracy of words and flows. This year we tended to do CC reviews using PDF artifacts exported from Mural or Figma designs before the screens were even built (which removed the need for this workflow step in most cases). In the future, we may be able to do more of these using the product itself. Its intended use: when a batch of screens in DF is ready for CC, you can you can update its workflow step to CC Review to temporarily lock screens to changes and signal to reviewers which screens are ready for their review.

Step 4: Translation check

This is a must if any screens in your batch added, removed, or changed content. Translation check step is how we highlight for the translation team what's ready for them in the UI and lock it down from further changes while they work. Changing the workflow step to Translation check alone isn't enough to get this done, we still have to put in a ticket for a translation check. But we use the batches and workflow step as part of those request tickets: we export all the content in the whole batch for their review and then direct them to the batch on All Screens so they can see the screens in context. Once the translation is done, a ticket will be made to put the Spanish text into the screens. When both translation and updating the screens with Spanish content is done for all the screens in the batch, the batch workflow can be moved on to the next step.

Step 5: Complete

Complete and close. When a batch of screens has completed the necessary steps to be publishable (meaning all screens in the batch have the approved English and approved Spanish content correctly displayed), it's time to complete and close the batch. The screens in the batch are now updated to publishable screen state (unless they're members of additional batches still in earlier workflow steps).

The content approval process is baked into the batch workflow

The content approval process is part of the batch workflow and is reflected in its workflow step names. This process has designated reviewers for the checks we do in English and Spanish. Not every check is called for with every screen change, but use your best judgment. For example if you changed no words, then Editorial and Spanish checks aren't necessary. If the only thing you changed was words, then the Design Cohesiveness step might be skipped. In general, we run newly added content and designs through all the checks, but iterations on items already checked have greater flexibility. See the content approval process for directions on requesting DF reviews, CC reviews, and Translations.

All Screens

The All Screens view is what we use to see all1 the pages in the tax flow at once. Many of us use this tool to review the current state of implementation of screens or whole sections, to check for consistent text usage on different screens and modals, to see what tests a screen informs, or how to trigger conditional questions. We even use All Screens to create PRA artifacts—its uses are countless. It also displays labels describing the publication readiness of each screen.

1 The All Screens view notably lacks several screens like the checklist, the dashboard, the screener, and more.

Screen state labels

This year we introduced screen state labels to All Screens. These labels indicate publication readiness - or whether the screen is ready to be "published" and seen by taxpayers.

• If a screen is displaying approved content in both English and Spanish on the screen and its modals, and it's not been added to a batch that's being worked on presently, then it will have a green publishable label.
• If it's been included in a batch that's still being worked on, it shows a gray unpublishable label instead.

Batch details

Our batch workflow and content approval process help us take screens from an unpublishable to a publishable state with confidence that they're really ok to go live.

A screen can be in more than one batch at a time. That's expected behavior. The screen state label for unpublishable or publishable is a determination of the screen status made by rolling-up the states of the different batches the screen is part of.

Imagine a screen is in two batches at once. Batch A is complete but Batch B is still in Translation check. The screen will show that it is unpublishable because one of its batches is still being worked on. Once Batch B is completed, too, the rollup will change to publishable because there is no more unapproved work outstanding for the screen from either batch's workflow.

Batch details

Each screen in the All Screens view has a drawer header that can be opened to reveal tax tests and batch details. Click the + in the upper right corner and then expand the sections inside. The batch details section reports any open batches the screen is in as well as any that are now completed and closed.

Locking

Some workflow steps (DF Review, CC Review, and Translation Check steps) call for temporarily locking a screen to further changes. This is noted with a red label on the screen header that says locked. You can use the All Screens view to see if your screen is temporarily locked for Review or Translation check (this can happen by surprise if your screen is in multiple batches at once). Don't change a screen while it's locked. Once it's unlocked, you can proceed with further changes and complete the workflow for your batch. That will ensure this screen gets checked for translation again when the time comes.

Example of a "locked" label:

Filtering

In addition to other filters, All Screens now lets you filter by batch, workflow step, or screen state.

This is handy if, for example, you're looking for screens in the Translation Check step, you can filter by that workflow step and the view will update.

Content Batch & Workflow Glossary

All Screens

This is an internal tool that the Direct File engineers built to help us view and search across screens from one location. The All Screens view shows the screens in the tax flow (plus select others) flatly. This view provides tools for filtering by batch, by screen state, by workflow step, and much more. Screens in this view have a header drawer and labels that provide key metadata about the screen, like its state of publication readiness, any tax texts it contributes to, and its presence in batches, both current and historical.

Batches, content batches

A batch is a set of one or more screens. Each batch has a name, workflow steps, a lock indicator, and a publishability indicator. A single screen can be in multiple batches at once.

Batches are our way of grouping and tracking the screens we're working on as we complete the steps necessary to get them ready to go live.

Batches have a lifecycle: open or closed. Open a new batch to corral screens you're adding or changing, keep it open and update its workflow steps as you take it from first changes through Translation and completion. A complete batch is one that's publishable (approved English and Spanish content implemented on all its screens). When a batch is completed, it's closed.

Content approval process

The content approval process is a series of internal team checks and external Chief Counsel checks. It's often handled by the Design team who send screens to (1) a cohesiveness check, to ensure as DF grows it remains a consistent experience, (2) an editorial check, to make sure we're following our style guides, and (3) a Chief Counsel check, to make sure our tax logic and the way we talk about tax concepts look good to go. Clearing these checks results in screens that can go on to Translation and after that, can be published.

Locked, Locking

Locking is a condition that goes along with certain workflow steps to stop teammates from making further screen updates during a time when reviews are happening and shifting-content would complicate that task. For example, when a batch is marked for Translation Check, it's locked until that translation is completed and implemented.

Locked screens are indicated on the All Screens view with a red LOCKED label in the header to help people recognize when to hold off on making changes until the lock is lifted.

Publishable, unpublishable

Publishability refers to the launch readiness of a screen. This is shown on screens with a label of Publishable in the All Screens view. Screens default to unpublishable state. We reach a publishable state in DF by (1) completing the content approval process, (2) updating the content in DF with approved content in English and Spanish, and (3) updating the content batch to complete and closed.

Roll-up, screen status roll-up

One screen can be a part of multiple batches—even multiple batches that are open at the same time. It's important to know the status of a given screen based on it being a member of a batch (or several).

Screen status roll-up gives us the bottom-line TLDR for a screen, no matter how many batches in different workflow steps it's part of. Rollup summarizes two key pieces of info for a screen:

1. Is this screen currently Publishable or not?
2. Is this screen currently Locked or not?

Workflow

The workflow or "content approval workflow" is a series of steps that must be completed in order for a batch of DF screens to reach a state of "publishable." "Publishable" means all the content in the batch has been approved for going live in DF and the Spanish translation of that content is implemented, too.

Workflow steps

Workflow steps are the stages of the workflow a set of screens goes through to reach "publishable" state. We put every screen we created or updated this year through a content approval process. Those review steps are reflected in the names of the steps in our batch workflow. They are:

• WIP: Work in progress.
• DF review: Direct File internal or Tax SME review.
• CC review: Review by IRS General Counsel.
• Translation check: Content has changed and translation is needed.
• Complete: The batch has reached the end of the workflow and can be marked closed.

Zebra striping

We use a hot-pink zebra-striped bar to the left of screen elements that were changed as part of work on a batch to show at glance what elements we touched. Zebra striping only shows in the All Screens view while a batch is open. It goes away when the batch is complete/closed.

Insights to action

The Direct File team used a Lean UX methodology, monitoring data streams that track live use, quickly identifying issues, deploying experimental solutions, and measuring how well that mitigates problems. During filing seasons 2024 and 2025, the Direct File team was able to quickly, incrementally respond to problems in the taxpayer experience and inform the product roadmap.

The Insights to action process

To make sure this was an efficient process, the Direct File team operated under a few shared concepts for understanding and intervention:

1. Created team processes for understanding live use of Direct File. This included common disqualifications, rejection reasons, and customer service interactions. The team paid close attention to all indicators to understand how the service performed for taxpayers and where potential issues might be.
2. Approached issues as opportunities. When issues were identified, they became opportunities to iterate on the product and evaluate the impact of any changes.
3. Started with tightly scoped interventions. This enabled quick deployments and impact studies. If any issue was quickly solved, development effort could be redirected to other issues. If it wasn’t, there was time to try again.

Insights to actions team

This process required two partner teams: the Insights team, a cross-functional group responsible for monitoring different data streams, deriving insights, and briefing the larger team, and the Actions team, a Design and Product team responsible for rapid build-measure-learn cycles and updating the product roadmap. These two teams worked together: Insights' work fed Actions’ work, and experiments run by the Actions team ran gave the Insights team new items to monitor and evaluate.

The Insights team monitored and reported on key data streams weekly:

• Customer Support survey data
• Customer Support transcript data
• Customer Support Representative (CSR) daily feedback survey data
• Taxpayer post-submission survey data
• Backend data (tax return submissions, rejections, error codes)
• Usage analytics
• Usability testing
• Social media listening (comments posted to public platforms like Reddit, Bluesky, etc.)

The Actions team reviewed insights weekly and examined findings through a design lens, with a deep understanding of the tax logic and the return preparation experience. They investigated questions like:

• Were the numbers for a certain rejection code changing or otherwise unexpected? Why? What was the opportunity to address it in Direct File?
• Was there a high percentage of taxpayers asking CSRs a given question? Why? What could Direct File answer more directly in the product to give taxpayers the answer they need in the moment they need it?

From there, the process looked like this:

1. Identify an item for intervention, determine if an intervention could be done during the tax season. If not, put that item in the backlog or product roadmap.
2. If the item could be done during tax season, create a “tracked experiment,” including a hypothesis about how it would address the issue and how to measure the impact of the intervention.
3. Work with Design, Product, and Engineering to create and deploy an intervention and start measuring impact.
4. If the intervention didn't solve the issue for taxpayers, the team moved to the next intervention and measurement cycle until the issue was solved.
5. If it wasn’t solved by end of tax season, learnings were captured in the product backlog and roadmap as needed.