Using "Standards" in our name establishes misleading expectations

[thisisdano]

Since the beginning of the USWDS, we've been aware of the disconnect between the meaning of "standards" in a government context and what the [USWD]Standards actually are: voluntary guidance around best practices and a practical toolkit to build from that guidance. Plainly, we know that the Standards aren't standards and that's a problem. Since we're more interested in a living system of voluntary guidelines than a fixed mandatory standard, it makes sense to think seriously about changing our name — and we are thinking about this now as part of a larger process of refining our mission, principles, and product as the Standards matures.

Words have meaning, especially in government. It's a big thing to change a name, just as it's a big thing to misrepresent with that name. So we need to take this seriously.

Variations on this issue have popped up like 🍄🍄🍄 for some time:

• Could you make it clearer that this is not some sort of official regulation?
  (Could you make it clearer that this is not some sort of official regulation? uswds-site#197)
• Mandatory standards? (Mandatory standards? #1755)
• Clarify the role and status of this project in the homepage text (Clarify the role and status of this project in the homepage text #846)
• Call it the U.S. Web Design System (Call it the U.S. Web Design System #1518)

At one point we reached out to NIST with our question about naming, and this is how Patricia Harris at NIST replied:

Thank you for bringing your question regarding your group’s the use of the word “standard” to the NIST Standards Coordination Office. NIST is the chair of the Interagency Committee on Standards Policy (ICSP), so matters such as this are of great interest to us. I have consulted with a number of SCO staff with experience in standards development, implementation, and standards policy in the federal sector to comment and advise. Following is a summary of our viewpoints.

Based on our experience, we can understand why the agency representatives you are working with are confused about the use of the word “standard” in the context of your work.

Within the community of federal agencies, the generally accepted understanding of the term “standard” is set forth in the NTTAA and the recent revision to OMB Circular A119. This law and policy direct federal agencies to rely on standards developed by the private sector using a consensus-based process (some caveats and exceptions are noted). Some of the confusion you are seeing from your agency colleagues may be based on their knowledge of A119 and their expectation that standards are developed in the private sector (primarily).

In those cases, where the federal government develops its own standards, it is generally in the form of a regulation that is required for use by either the regulated community in the private sector or a requirement for federal procurement or use within the federal government (often in the form of an executive order or OMB policy memo.) This general acceptance that standards intended for use within the federal government are most often mandatory is the other source of confusion.

Your group’s decision to use the term ‘standards’ is entirely your decision to make. However, it may not be the best word to use. Referring to your document set as the ‘U.S. Web Design Standards’ could denote to some that this is a U.S. national standard and thereby assume that is applicable beyond the federal government and has the full authority of the U.S. federal government. We suggest your group consider a title that more clearly denotes that 1) this is a US federal government effort and 2) that this is not a mandatory standard. Some ideas to suggest: “Guidelines for federal . . .” or “Best Practices for federal . . . .”

We’d be happy to discuss this further with you and others. Let me know if you think a conference call with your team to discuss this further would be beneficial. Fyi, I have taken the liberty of cc’ing the GSA representatives to the ICSP, Jeffrey Thurston and Jennifer Moffatt.

Thank you for reaching out to NIST and giving us an opportunity to comment and advise.

---

I believe the key paragraph is this one:

Your group’s decision to use the term ‘standards’ is entirely your decision to make. However, it may not be the best word to use. Referring to your document set as the ‘U.S. Web Design Standards’ could denote to some that this is a U.S. national standard and thereby assume that is applicable beyond the federal government and has the full authority of the U.S. federal government. We suggest your group consider a title that more clearly denotes that 1) this is a US federal government effort and 2) that this is not a mandatory standard. Some ideas to suggest: “Guidelines for federal . . .” or “Best Practices for federal . . . .”

This is guidance we implemented at the copy level, and I think we've been responsible in communicating that this system is not mandatory. But it is possible that this is not enough, and the distraction of this continued naming issue, in addition to the very real confusion it causes, is reason enough to be serious about considering a name change.

The USWDS is commonly called "the Standards" and this name has stuck. For better and for worse, this name has recognition and connotes a certain gravitas. The mission of the USWDS has importance and gravitas we wish to maintain, even as we push for living, iterative, opt-in guidance. What kind of a change can we make that makes sense, provides continuity with the current name, and furthers our mission. This is not a simple question.

We expect that this will be a place for folks beyond the Core team to discuss this issue, and it is the appropriate place to discuss this issue. Anyone is welcome to join in. Welcome!

[wslack]

I would suggest people read through #1518 for the thoughtful comments - thanks for referencing that issue Dan. I listed some alternative name ideas there last time we discussed, though I admit recent feedback has changed my view a bit.

I don't think the current name misrepresents (strictly speaking), though it does have a potential of confusion. We're in a space that intersects several competing sets of norms, and in the world of web design, a "design standard" isn't legally required. It represents best practice and allows for a consistent experience (e.g. http://www.justinmarxdesign.com/nordstrom-ux-design-standards/ https://www.uxmatters.com/mt/archives/2014/08/principles-over-standards.php https://uxplanet.org/7-deadly-ux-sins-and-how-to-avoid-them-f47292e1f5dd http://digitaldesignstandards.com/ http://design.comcast.com/standards/)

In other words, a "design standard" is policy, not a legal mandate.

Here is the policy guidance from OMB M-17-06:

18. Ensure a Consistent Look and Feel Across Websites
    Common user interface components and visual styles help create a seamless transition across an
    agency’s websites and improve the ease with which the public can find information.
    Federal Agencies should ensure a consistent look and feel of their public facing websites and digital services.

The U.S. Website Design Standards, found at https://playbook.cio.gov/designstandards/gettingstarted/,
is available to all agencies to assist with this process.

I think this says that it is policy for agencies to have a consistent look and feel - which means that agencies should be working off of "design standards." The USWDS are an example set of standards.

I don't think its quite fair to say, within this context, that the USWDS are supposed to only be "voluntary guidelines." We know from talking with partners that the "standards" name has been helpful within agency internal discussions about web design - they have been useful resources "in the corner" of developers arguing for better practices on their websites. They assist agencies in doing the right thing - though agencies can promulgate their own design standards to serve the OMB ask, instead of leaning on our general product. US government web design is in a better state right now because civil servants "lean on" the standards to do the right thing for the users.

Finally, in line with the NIST guidance, the USWDS are meant to "import" best private industry practice into the government. They are completely in line with that part of the guidance.

My suggestion would be to determine what you want the name to accomplish and then look at various possibilities against that criteria of success. I agree that "standards" can cause confusion, but if possible, I don't want to give up all of the benefits that the current name allows for the government. I wonder what other names can continue these benefits and be accurate in industry parlance without the possible confusion that's present today.

[AndreaSigz]

I will also share this thread @thisisdano to the listserv, replying to the several emails about this in the last few days; directing them to this GitHub issue

[thisisdano]

@AndreaSigz I'm sending it out to the listserv now :)

[thisisdano]

@wslack Thank you for jumping in! I definitely realize this is an issue with roots and existing thoughts. The Standards vs Design Standards distinction really resonates with me because of how familiar I am with design standards, standards manuals, etc. It's definitely aligned with the Design Standards Manuals developed for the Federal Design Improvement Program in the 1970s. (Which I truly 😍 btw.)

And I think you're right, misleading is probably a little harsh. But I also think it's real, and the distinction between a standard (as in OMB Circular A119) and a design standard (perhaps more of a term of art) is not as clear in the government context.

My suggestion would be to determine what you want the name to accomplish and then look at various possibilities against that criteria of success. I agree that "standards" can cause confusion, but if possible, I don't want to give up all of the benefits that the current name allows for the government. I wonder what other names can continue these benefits and be accurate in industry parlance without the possible confusion that's present today.

☝️ This is good advice.

[konklone]

I agree that "standards" can cause confusion, but if possible, I don't want to give up all of the benefits that the current name allows for the government.

I think the issue is that, to the extent there are benefits that the current name allows for the government, it's based on the "gravitas" the word "standards" has in the government, which is directly connected to the general government expectation that standards are mandatory.

So I think it's difficult to have our cake and eat it too on this one, and would recommend we move to U.S. Web Design Resources or U.S. Web Design Toolkit (or something like that), which may have less gravitas, but is more likely to communicate the role of the project more effectively and generate less confusion.

[thisisdano]

I think the issue is that, to the extent there are benefits that the current name allows for the government, it's based on the "gravitas" the word "standards" has in the government, which is directly connected to the general government expectation that standards are mandatory.

Oh boy that. It's unfortunately kinda "part of this complete breakfast"-y. But undeniably effective.

[danamuses]

From the perspective of an agency that has begun to implement the USWDS across our platforms, I have found it to be incredible helpful in my outreach to stakeholders that these are "design standards." I like to point out that there is flexibility within the standards (e.g., multiple ways to apply the font choices, a pretty wide color palette). I also often frequently note that these standards have been developed based on expertise in usability and accessibility--so the fonts were chosen because they are readable (and not "just because" or "they look nice"), etc. If this were simply a "toolkit" or "resources" I would have a much harder time selling them as something we should adopt and implement. So put me as a check mark in the "keep name" column, please!

[thecapacity]

I for one am not sure I understand the nuance, but I would leave the name because I think the cognitive work isn't worth the collective value.

Also my read of A119 perhaps differs from NIST, which may not be surprising given some of my other views on FIPS and SP-* however it seems to:

1. Define standards as voluntary which is entirely what the USWDS are... i.e. they seem aligned w/ the definition and
2. It seems to empower NIST to "coordinate conformity assessment activities of the agencies..." vs. relying on NIST to define them, i.e. I read that as NIST is fully empowered (but not obligated) to build an assessment tool, much as they've done for other "standards" (like IPv6)

While I'm on the subject of IPv6, I'd note that NIST didn't define that standard (though I'm sure they had a valuable part in it) and it's entirely voluntary as a technology standard - i.e. if you don't want to be part of that community you don't use it... and having a standard mandated comes more directly (e.g. as part of an OMB action)

[lanebecker]

Curious about whether or not the phrase "design system" was rejected, and if so for what reason. Earlier discussion doesn't appear to end conclusively one way or the other, and it does seem to be the thing the CMS fork/Nava team went with.

Not an endorsement of that approach, just curious.

[andrewmaier]

Context matters more than consistency in design. My vote would be to offer guidelines in the spirit of, say, Apple's Human Interface Guidelines. Design guidelines should encourage consistency while also empowering folks to make well informed decisions about the tradeoffs they're making throughout the design process.

[thisisdano]

@lanebecker I believe "design system" is probably the most accurate descriptor of what the USWDS is — at least in contemporary usage. I'm not sure what currency that usage has outside design professionals (yet) but it is the way I describe the USWDS to others, and I would say that's how we think of it internally as well. The Nava/CMS system is very interesting to us, and a useful example in many ways!

@andrewmaier I'm sympathetic to that point of view, and I'm curious how more high-level guidance (at something of the level of HIG) might be important to our system, because, as you've probably seen yourself, USWDS projects deviate from the standard styles far more than they conform to them. I think this is a feature, not a bug, and we expect that this will continue. And because it will, higher-level guidelines are much more important, since we wouldn't want necessary customization to be inconsistent with critical best practices. How can we encourage adaptability within a greater system of good-for-people design (as a verb) consistency?

[philipashlock]

One of the main reasons why this is such a hot button issue is that the existing use and understanding of the term "standards" in government is quite confusing and ambiguous to begin with. So this isn't just a matter of sowing new confusion, it's adding confusion on top of existing confusion. That is of course further exacerbated by simply referring to this work as "The Standards."

While the folks who focus on web content and web design may be less familiar with these issues, it seems to add unnecessary confusion to something that would already benefit from more clarity. Personally, I think the more appropriate term which is already well established for this community of practice is the U.S. Web Design Styleguide (maintaining the USWDS abbreviation). To the extent that the styleguide incorporates things that are explicitly mandated (like Section 508 accessibility requirements) perhaps that can provide extra weight to convince those who need it. Given how passive the language around the reference to USWDS is in M-17-06, I think it's quite a stretch to treat it as a standard in the form the term more commonly takes in government and I don't think that was OMB's intent.

---

Here's my broader diatribe on the term "standards" in the U.S. Government...

Ambiguity and miscommunication around the word "standards" is not unique to government and many efforts outside of government avoid using the term or only use it with more articulate qualifiers. For example, the W3C which is the main standards body for the specifications that make the web work, refers to their work product as "recommendations" rather than "standards." In part, I think this is to connote that you can rarely designate a standard by fiat, something only truly becomes recognized as a standard through broad real-world adoption. This is where the government is unique, it can and does designate things by fiat. In fact many laws and regulations are effectively synonymous with the use of the word "standard" in government. When someone says, "is that thing built to code?" they're asking if it's built to the standards defined by government in law.

As government becomes increasingly digital and data driven, the ambiguity around this term in Federal policy seems to be more problematic. While many folks, including myself, have often pointed to the NTAA and it's authority thru OMB A-119 as the main policy governing standards and participation in standards development with regard to data and digital systems, I don't think the law was really written with this use in mind. Or to the extent that it was, it seems to be more of an afterthought. In practice it doesn't seem to be serving this purpose very well as you can see by relatively little mention of data standards or digital interoperability in the annual reporting for A-119 (Commerce's latest report from 2016 may however be a good counterexample)

My understanding of A-119 is that it was primarily meant to focus on standards that govern the build and process around physical things to ensure they meet minimum requirements for how they're produced or perform in terms of quality, safety, reliability, environment, etc. You can consult the current copy of A-119 for the full definition (the copy on Whitehouse.gov seems out of date) and it does include a wide range of descriptors to define a standard. Many of these seem to be framed more around "physical things" and there's similar language used to describe NIST's purpose e.g. "manufacturing technology, quality control, and techniques for ensuring product reliability" and "Precise measurements, calibrations, and standards help United States industry and manufacturing concerns compete strongly in world markets."

While the original definition in the NTTA is quite short ("the term `technical standards' means performance-based or design-specific technical specifications and related management systems practices") the incarnation in A-119's definition as well NIST's charter does include a little language that's more explicitly applicable to data and digital systems, but they're still short and brief compared to all the focus on those more physical things. In A-119 it's "formats for information and communication exchange" and in 15 U.S. Code § 272 it's "develop and test standard interfaces, communication protocols, and data structures for computer and related telecommunications systems;" In practice the main activities I seem to be aware of that fall into this category are things that also have more specific mandates under this like NIST's role in ensuring minimum standards for cybersecurity or digital infrastructure for voting systems whereas broader work for data standards often tends to come out of non-NIST efforts, e.g. NIEM, or through specific mandates, e.g. the DATA Act and the DAIMS, M-13-13 and data.json, M-16-21 and code.json, etc.

It turns out that OMB A-130 does give the Department of Commerce (NIST's parent) more emphasis on having government-wide responsibilities here and GSA is also named as being a partner. Although that authority still seems to be derived from the NIST Act and A-119. From Circular No. A-130, Part 6:

The Secretary of Commerce shall: Identify needs for standardization of telecommunications and information processing technology, and develop standards, in consultation with the Secretary of Defense and the Administrator of General Services, to ensure efficient application of such technology;

A-130 also puts emphasis on "open data standards" but I'm not aware of much guidance or definition to support those roles and terms. For interoperability between digital systems most developed countries have something like a "National Interoperability Framework" but I'm not aware of equivalent guidance in the U.S. Government.

As has been already mentioned in comments here, it seems like it would be better to define the use of a standard in terms of what goal(s) standardization achieves rather than simply use the types of specifications or processes that define the context where standardization is applicable or achieved. In the case of A-119 it seems like the main purpose is "conformity assessment" - to be able to have an apples-to-apples comparison to ensure something meets a minimum set of requirements. This is different from the purpose of most standards in a digital context, or at least it's a much more limited scope of purpose. Here's how it's defined in A-119

What is Conformity Assessment?

"Conformity assessment" is a demonstration, whether directly or indirectly, that specified requirements relating to a product, process, system, person, or body are fulfilled. Conformity assessment includes sampling and testing, inspection, supplier’s declaration of conformity, certification, and management system assessment and registration. Conformity assessment also includes accreditation of the competence of those activities.

We should put more thought into the use of standardization or "conformity" for multiple purposes beyond that type of assessment. I started to list some examples below, but some of these will surely overlap or serve as foundations for the other.

• Conformity to ensure mutual understanding (definition of words, fundamental units of measure)
• Conformity to ensure minimum requirements - enabling conformity assessment to ensure something meets a minimum requirement or best practice (e.g. standards for safety or environmental regulations)
• Conformity to ensure aggregate harmonization and comparative analysis
• Conformity to ensure functional interoperability (or modular interchangeable parts)
• Conformity to ensure accessibility and expected user experience conventions
• Conformity to ensure consistent brand identity and voice

On a related note, I've been looking for an anatomy of digital and data standards that break it down into the multiple layers of standardization. I started to sketch that out in this comment.

[bendygirl]

Is this now OBE with this issue #2300
specifically this:

Change name and shorthand throughout main repo and docs site
Write a blog post to explain the change as relevant to the work we’re doing and what we’re providing -- @thisisdano
Less about the name, more about the benefit, pedagogy — benefits of system design thinking, similar to standardization without the baggage, rigidity
Pick a URL: designsystem.gov / designsystem.digital.gov -- @thisisdano cc @jeremyzilar

So, I can't read the accompanying document, but is there a time frame for when the blog post and name change will take place?

[maya]

@bendygirl thanks for reaching out. Yes, #2300 is where we're tracking work needed to be done for the name change. It's a top priority for the team and we're working on the announcement this sprint and will be able to share it with you soon. Thanks for your patience.

[bendygirl]

@maya I've also noted this on the content list, and I referenced my comment so anyone who hits the link should be able to follow along. You might want to respond to the email if possible that work is being done in this vein. I have been going through the issue que to see since this open ticket wasn't apparently cross referenced (at least not that I could find).

Thanks

[maya]

@bendygirl cross-referenced now and we'll share the announcement via the email as well, thanks!

[bendygirl]

I've posted to the internal drupal lists so the govies also know where to find the info on this moving forward.

[maya]

Hello everyone,

After listening to a lot of thoughtful feedback and discussion from a wide range of voices in the government web community, we’ve decided to change our name to the U.S. Web Design System. (You don’t need to update any code for this, it’s simply an announcement.)

Here’s why we’re making the change:

• We wanted to clarify our project: they’re not mandatory standards, but a system of tools and guidelines that anyone can choose to build better government websites and services.
• Standards also suggests something fixed and rigid, which is the opposite of our goal to create a design system that’s flexible, modular, and always learning from its users and modern best practices.
• It’s a system whose various parts (e.g. visual design, accessible color combinations, interactive components, page templates, etc...) can be used bit by bit, all together, or extended into something new.
• A Design System is the real-world name for what we do and what we are. All kinds of organizations—from governments to large corporations—use design systems to help guide the design and development of their digital products. So we'll be consistent with real-world usage as well as gov-specific terminology.
• Conveniently, we don’t need to change the acronym (USWDS).

Moving forward as the U.S. Web Design System is the right thing to do and will strengthen the system going forward. Our mission to provide research-backed design patterns for building accessible, responsive, and consistent digital products for the federal government is as important as ever, and we're focused on improving what we do and the benefits we provide to those who use what we make.

We’d like to thank everyone for contributing their time and expertise to the discussion and your patience as we worked through this issue. We’ll begin rolling this out in the next few weeks (see the task list). We look forward to continuing to work together in the coming year.

Thank you,

USWDS Core Team
Dan O. Williams, Maya Benari, John Donmoyer, Andrea Sigritz

P.S. If you’d like to see what we’re working on next, check out our 2018 Product roadmap.

[stphnwlkr]

Thanks for the effort on this. I was a fan of "standard", but I understand the need to adapt. Looking forward to system updates.

[maya]

Closing this as we begin implementation in #2300 (comment). Thank you!

[bruce-usab]

Thank you @maya and @thisisdano et al.