Skip to content

Decision: item design direction

Jonathan Stegall edited this page Sep 22, 2023 · 12 revisions
Thing Info
Relevant features Policy repository item design; potentially other item designs as well
Date started 2023-09-22
Date finished
Decision status first draft
Summary of outcome

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:
    • image
  • Homepage version:
    • image
  • Resource sidebar version:
    • image
  • Resources page version:
    • image

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.

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

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
  • Which fields are currently displayed
  • Emphasis/order of the fields
  • View document button
  • Designed with subjects
  • Designed to support multiple dates for a document, if relevant
  • Designed to connect dates with groups/owners/individuals
  • Designed with possibility of states
  • Designed without multiple levels of document type
  • Designed without summary/teaser
  • Designed to expand/collapse regulation and statute citations separately

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:
    • image
  • 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?)
  • 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.

Overview

Data

Features

Decisions

User research

Usability studies

Design

Development

Clone this wiki locally