Defining design principles for the cloud.gov dashboard redesign

[beepdotgov]

In brief: Documenting some design principles would help us identify how cloud.gov talks about “good” or “successful” product design, and help 18F ensure the redesign is properly aligned with those principles.

Why this is helpful: Design principles are more than aesthetic assessments like “clean” or “intuitive”: they’re an expression of a product team’s shared values. Those values are often implicitly understood by a team. But by documenting those values — making them explicit — they become a shared language a team can use to better inform their product’s design.

18F talks about what makes a useful design principle:

• Helpful design principles bring your priorities into clearer view.
• Design principles should represent insights from user research and engage the history and culture of the sponsoring organization.

For the dashboard redesign, defining cloud.gov’s design principles will have two benefits: it’ll help 18F put forward initial concepts that are better aligned with those principles; it’ll also help us conduct better design reviews, grounding our feedback discussions in those principles.

Additional resources on design principles:

• Developing Design Principles
• Design Principles at Microsoft
• Creating Great Design Principles.)

Process: Given the work that's currently in-flight, we'll adopt a two-step process here:

1. A review of initial design work. I’d like to do an hour-long review of some design work that’s been done. This would allow us to talk through its current design gaps, and discuss in more detail why something is or isn’t working. Documenting these underlying assumptions can help us identify cloud.gov’s shared values around design, and help us better align the design with those values. (It’d also be valuable context for me!) I was thinking that this should be a smaller working group of @hursey013, @sknep, @lauraponce, and myself. But open to thoughts on this!
2. A design principles mini-workshop. This would be an hour-long facilitated discussion to define some shared principles and values we bring to the design of cloud.gov’s products. To do so, we’d use three sets of inputs to help seed the discussion: concepts from the design review session, key lessons from the recent user research findings, and cloud.gov’s own customer service objectives. The output of this session would be a document outlining the principles we’ve heard, which we could iterate on throughout the remainder of the engagement. (And that cloud.gov could continue to update — design principles do evolve!) I was thinking this could be a session including more/all of the redesign team, but with the smaller session's working group as the only required attendees. But again: open to thoughts on this!

Timing/Priority: We chatted a bit about this yesterday, but I think this work would be good to prioritize as soon as possible. Aligning around some initial design principles will help us move the design forward more effectively. (I’d also love thoughts on how best to sequence this with 340 and 341, too.)

Acceptance criteria

• [x] Complete design review, and document findings (#356)
• [x] Complete design principles workshop, and document findings (#357)

[beepdotgov]

@hursey013 Should I draft separate issues for each of the two different working sessions, since they're separate-but-related streams of work?

Also, let me know what you think about the timing for 340 and 341. I might be inclined to treat the design principles as a blocker for starting on new component designs, but I'm 100% open to other ways of sequencing all this!

[hursey013]

I'll defer to you on your first question - I'm fine with either approach. As for #340 and #341, I agree getting the design principles squared away is the priority, with the hope being that the output of those conversations will help inform how we design components moving forward. We can pull those issues back into the backlog if it makes sense as well in order to focus on the tasks your outlined above - let me know your thoughts.

[beepdotgov]

Amazing all around --- thanks, @hursey013.

I'll defer to you on your first question - I'm fine with either approach.

Wonderful! I'll write up sub-tickets for each session, just to have those documented.

As for https://github.com/cloud-gov/cg-ui/issues/340 and https://github.com/cloud-gov/cg-ui/issues/341, I agree getting the design principles squared away is the priority, with the hope being that the output of those conversations will help inform how we design components moving forward. We can pull those issues back into the backlog if it makes sense as well in order to focus on the tasks your outlined above - let me know your thoughts.

+1, I think moving #340 and #341 to the backlog for now makes sense. I've got some good early ideas for both tickets, but having a shared language to talk about design is going to make the work stronger.

Thank you again!

[beepdotgov]

(Just logged the two sub-issues in #356 and #357; listed them as acceptance criteria above.)

[beepdotgov]

Closing this out, as #356 and #357 are both completed! 🎉