Design Challenge: Congressional Vote Data

Zachary Schuessler
8 min readJan 2, 2020

--

User interfaces are designed in hope that at a glance, users understand complexity without thinking.

Naturally the most challenging projects involve elaborate data. Today’s challenge: the United States Congress.

Let’s talk voting.

What We’re Up Against

Congress does a wonderful job ensuring voting data is provided to the public.

Let’s see an example of it below.

http://clerk.house.gov/evs/2019/roll217.xmlRetrieved 12/29/2019

We don’t need a full analysis to say this design could use UX finesse. But don’t fret, this is an opportunity to build our requirements for improvement:

  1. Readers must be able to understand information “at a glance” — meaning roughly a second of review
  2. Must be able to tell which party favored the vote, if any
  3. Must be able to tell how controversial the vote was for a given party; and
  4. Must be able to understand if the vote was close, or a landslide vote from both sides.

Let’s also consider our audience. Your typical reader doesn’t have a political science degree, and we want the design to be accessible to everyone.

We’ll add one more requirement:

  • Must be intuitive to a twelve-year-old.

Predesign: What are Others Doing?

After defining data and requirements, and before designing, it’s helpful to see what others are doing first. Standing on the shoulders of giants is a great way to save time!

This challenge is particularly interesting because so few projects are designing for vote data. Unfortunately, this rare subject didn’t have examples on Dribbble.

Let’s see what came up in Google search.

Example #1: Legiscan

https://legiscan.com/US/rollcall/HB5/id/867034Retrieved 12/29/2019

The Legiscan example above introduces the idea of using color and grouping data into a more understandable format. This is an upgrade!

We may glean ideas in using color from this example, but much of our requirements list seems to have been left open.

Example #2: ProPublica

https://projects.propublica.org/represent/votes/116/house/1/700Retrieved 12/29/2019

ProPublica introduces the idea of grouping data based on what we want to see: if the vote failed or not and what party voting lines were.

Instead of merely offering data, ProPublica took an extra step to think about what the user’s intent was. Excellent!

Suspect requirements that jump out here include the ideology chart to the right. Who is the intended reader? Probably not our twelve year old user without a polysci degree.

Those with the political science degree also might find difficulty in our “intuition at a glance” requirement. Let’s keep looking for inspiration.

Example #3: GovTrack.us

https://www.govtrack.us/congress/votes/116-2019/h217Retrieved 12/29/2019

This is truly fantastic! At a glance it feels intuitive.

GovTrack takes a step further in making user questions accessible at a glance, particularly with party voting lines.

Now that we have inspiration to work from, let’s try finding out why it feels intuitive. Maybe we can upgrade.

🖊 Design Upgrade #1: Design for Outliers in Data

When designing it’s prudent to always test for lack of data, excessive data, and common use cases of data. Designing only for perfect data causes problems.

Here, empty boxes (pertaining to a “No” vote) may be confusing to your average reader. This design would be more baffling if 0 Republicans voted “Aye”.

Using color theory, it’s possible to remove reliance on a chart key, and instead design to “at a glance” intuition.

Like proper scientists, let’s first validate that the assumption is true: outlier data is a problem.

Note: I Photoshopped the original chart to mock a quick example

Can you read the chart without looking at the key? The box lines are confusing.

Our eyes look at the chart, then to the bold vote count numbers because we aren’t sure what the Republicans did. The key helps, but it violates the “at a glance” rule.

Let’s try something different: instead of a box stroke, let’s use lightness of the original hue to indicate a “No” vote.

Furthermore, let’s test all outlier data to make sure the solution works in every case.

Test for all use cases!

Much better! Here we used more contrast between the same red/blue hues to indicate “Aye” and “No” votes. At a glance we understand the intent to communicate lack of data, or negation.

Always design for outliers upfront. No data, some data, ideal data — design for all three.

Any extra time spent in outliers is oft made up in development and redesign phases.

🖊 Design Upgrade #2: Answer The Most Common Question First

What do you anticipate is the most common question for this vote chart?

Without surveying, we can likely agree that the question is whether the vote passed or failed.

Other questions on party affiliation, party lines, etc — those are answered by deeper introspection of data, and thus, are secondary questions.

Let’s take a look at GovTrack again. Try to answer this question: did the vote pass?

Well, did it?

A twelve-year-old must learn Congressional voting rules to answer the question. Consider these questions:

  1. Did we need a half majority to pass, or a two-thirds?
  2. Do we count non-present members in the calculation, or just those present?
  3. How close was the vote to passing/failing?

Let’s simplify this.

Readers innately understand the meaning behind a progress bar. Let’s add one here.

The progress bar is helpful because at a glance, the most common question is answered immediately.

To further reduce complexity, let’s add an indication of the minimum vote count required.

This is my favorite upgrade. All we did was add a 1-pixel gray divider. It feels intuitive!

🖊 Design Upgrade #4: Human Perception of Grouping and Sorting Data

We’ve crossed off one of our requirements, but we have two more. We must be able to tell how a party voted at a glance.

Humans are great at recognizing patterns and making assumptions about them. Unfortunately, that occasionally makes for a more difficult design process.

Watch what happens when we group party data, then sort by “Aye” votes.

💭 Design 1: Group by Party, then Yea votes

The color groupings are here, but the design itself is jarring due to the gap between each party’s “Aye” votes.

Let’s try a few more edits.

💭 Design 2: Group by Yea Vote, then sort on Party

This seems better at first glance! But how many Democrats are there compared to Republicans? The “Nay” votes are too light to compare at a glance.

We also know that using empty boxes for “Nay” votes gets confusing, too. That’s not an option.

What if we went back to the first option, but shuffled votes so we knew what the party lines were?

💭 Design 3: Group by Party, then shuffle votes

The grouping of this chart solved our problem in Design 2 regarding party lines.

But now think about humans: we like patterns. The shuffling is jarring because we can’t, at a glance, detect a pattern.

Idea: we weight the shuffle of votes within each party so that 80% of the “Aye” votes for a party are sorted. Then randomly scatter the remaining 20% into the wind.

Let’s try it.

💭Design 4: Group by party, then Yea votes; shuffle the last 20%

This looks fantastic.

  1. At first glance, the chart allows your reader to easily gauge which party had a majority of “Aye” votes.
  2. It preserves party representation by fully dividing the parties.
  3. And finally, it resolves the jarring gap issue from Design 1.

Nice.

🖊 Design Upgrade #5: Consistency in Grouping

Thus far we have always shown the party majority, Republicans, on the right.

Does that make the most sense, or should we show the voting majority on the right instead?

Let’s see some data — pay attention to how you perceive the first row compared to the second.

Sort by highest vote

If I’m the reader, I’m confused. I don’t like it.

Sort by party majority

I went into this test knowing that fundamentally, you should almost always group on highest consistency and frequency in data.

Grouping consistently in this manner lets your power users make assumptions in reviewing a long list of data.

The top row is jarring because the difference in color and positioning forces us to slow down and consider why the layout is changing.

A party majority may change from one congressional session to the next — certainly less frequent than the many votes which take place! So let’s keep it on the right.

It’s good idea to test and confirm your theories. Even when you’re sure of them.

Wrap It Up: The Final Test

One of your final tests for a design is to use it in a real layout.

The requirements:

  1. Must be able to tell which party favored the vote, if any
  2. Must be able to tell how controversial the vote was for a given party
  3. Must be able to understand if the vote was close, or a landslide vote from both sides; and
  4. Must be intuitive to a twelve-year old.

With those requirements in mind, let’s see which design comes out on top!

#1 — Legiscan

#2 — GovTrack

#3 — The Redesign

And there it is!

Maybe it’s not perfect, and more user testing and template design is required. But at a glance this feels like an upgrade — wouldn’t you agree?

Wrap Up

See code for this widget below:

https://github.com/use-civic/congress-vote-widget

Thanks for reading 👋

Special Thanks

Special thanks to my wonderful sister for editing this (and many other!) articles. Much in readability and cadence is owed to her.

--

--