Decision: item design direction

Thing	Info
Relevant features	Policy repository item design; potentially other item designs as well
Date started	2023-09-22
Date finished	2023-10-03
Decision status	Done
Summary of outcome	Stick with existing item styles deployed on the combined search page, with the addition of clickable subjects. We want to work on evolving toward incorporating patterns from this new design, but will need to do it across the site.

Background/context

We have several directions we could go with how the items are presented:

1. Stick with the design we have and make minor changes to expand/extend it to cover new fields. Implement across the site.
2. Determine that a more deeply modified design is better to accommodate new fields. Implement across the site.
3. Something in between.

If we do decide that major changes are important across the site, we'd have to figure out how to prioritize implementing that against other work, and how to help our users get familiar with it; we'd need evidence to justify it as more important than something else.

Core questions

1. How much change do we make to the design for items?
2. How do we apply any changes we do make to different parts of the site?

What we know

We have a significant amount of information about what types of items we store and the data we have about them. It's mostly consolidated in this structure and content document.

What we've done so far

We have an existing design history of resources. Its most current iteration is used on the combined search page. The same design language is also used in resource sidebars, on the homepage, and on the Resources page. There are variations based on placement and use, but the overall structure is the same.

• Combined search version:
  • 
• Homepage version:
  • 
• Resource sidebar version:
  • 
• Resources page version:
  • 

We also have a proposal designed specifically for the fields associated with internal policy repository documents. This design was made with the assumption that it would only apply to internal documents, and that we'd learn through further research how to prioritize the possible fields for each document. Here's the Figma to show this design in context.

• Version that shows the most fields:
  • 
• Version that shows fewer fields, focusing on what we currently have data for:
  • 

Main differences the new version introduces:

• Font sizes used (uses different sizes for things, and a generally higher size, although all the sizes are used elsewhere on the site)
• Doesn't have all of the other design variants defined, which are likely important. Mainly this means there's no sidebar version, and no homepage version.
• Which fields are currently displayed
• Emphasis/order of the fields.
• View document button. This could be helpful in reducing the amount of time someone has to look for what to click, especially with a lot of fields where it's not necessarily clear what to click on.
• Designed with subjects. This is a new component.
• Designed to support multiple dates for a document, if relevant. We could collapse/expand them, if we determine that it's relevant to include upload dates, modified dates, etc.
• Designed to connect dates with groups/owners/individuals. This is intended to allow dates and people to go together, like they often do on a news article.
• Designed with possibility of states. We aren't sure yet whether this is necessary. If it is, it's designed to go next to the document type.
• Designed without multiple levels of document type. Some documents in the existing version have a document type and a document subtype, although many do not.
• Designed without summary/teaser. This is minor for now, but important if/when we incorporate full text search. The Figma file does have a setting for that, but there isn't really any example data to show yet. It's a relatively solved design issue, but it's not currently used very much in the design.
• Designed to expand/collapse regulation and statute citations separately. Right now, it uses REGULATIONS in all caps; in all likelihood I think we might want to stop doing that if we use this design. Similarly to how Publish Date is not capitalized.

How the Figma works

In the Figma file (edit mode), there is a result item with two main variants: "Search Page" (because it's derived from the search results page) and "New".

When using the component, you can switch between the variants and configure which fields will show up:

Both versions are at what I would call a relatively early stage. They need some refinement and some decisions (hence this document), and once a decision is made, there'll be some additional design work to do.

What we don't know

• How does the usability on the two versions compare?
• What are the implications if both versions exist?

Things we need to decide + options for them

• Do both versions exist? If so, is the inconsistency worth it? Is there a small roadmap for reducing the inconsistency gradually?
• If only one version exists, which one?
• If only the existing version exists, how do we incorporate new fields?
  • There's a rough version of that in the Figma:
  • 
• If only the new version exists, there are several things that might be on those documents that would need to be integrated

Consequences

• If we don't decide to only use the existing version, we'd likely have a new design inconsistency for some amount of time.
  • We do already have several similar inconsistencies
  • We could define a small design consistency roadmap and set of stories. It might involve reducing the variation across the site on: spacing, font sizes, colors (basically our design system status document). The already-existing grid system would help dramatically with this.
  • We'll likely have more of this kind of work anyway with needing design changes on the header and sidebar, and the main reading experience if it is affected by the grid.
• If we do decide to only use the existing version, we'll need to revise it a bit.
  • Make sure the subject design works well
  • If we like the separate "view document" link, we could add it
  • We should investigate how much work it is to incorporate that component into the new page design (I'm guessing it's not much extra, but is that accurate?)
  • We do still have a lot of design inconsistency and it may be difficult to get to it if we don't introduce new elements when we have the space. This is not bad, but worth noting.
  • We would need to make sure that the new sidebar design for the policy repository does not conflict with the existing document design. I think it's fine, but we'd need to give it a solid look.
• If we decide to only use the new version, we'd have some significant work:
  • Make a version of public documents that can go alongside the internal ones
  • Make a version of the new design that can go in all the other places

I think in writing this that I've persuaded myself that it might be better to just use the existing design and revise it, if that is viable.