Little rules for designing with data
written by @meiqimichelle; h/t to Ultrasaurus and her little rules for working life for page name and style inspiration.
We've all done it. Mocked up a perfect dashboard with evenly-spaced bars on the bar charts, each with a readable label (because of course all the bars are big enough for that). All the boxes look so nice, evenly spaced. Then, in comes the data, and it's a jungle out there! The biggest value on the bar chart is huge, rendering the rest of the bars unreadable. We forgot to design for what we thought were mere edge cases (data-equals-zero versus data-equals-no-data, anyone?). Some labels are coming in at one word, and others hefting across at seven, nothing is lined up anymore! Worst of all, with a launch deadline looming, there's no space to make it better.
...But it doesn't have to be this way. Here, documented, is the user-research- and data-driven design and prototyping process that created https://useiti.doi.gov/. This page is called 'rules' but I encourage you to think of them more as 'guidelines.' Improvise from here and form a process that works for you and your team.
Your reward:
- Team flow that creates designs that fit the data
- Data that communicates clearly
- Do user research without assuming what data or content your user groups are interested in. Check out our wiki home page for links to examples of this process.
- Get yer data! For reals! No mock data! The real deal data you'll need to display!
- Start to learn what this data actually says (and does not say) through throw-away prototypes, writing human-readable sentences, and design studios with your entire team.
- Build out your best design ideas just enough to be able to show them to your target audiences, learn things.
Repeat steps 3 and 4, keep learning, iteratively! Launch when there's something that provides a minimum amount of value to your audience, continue learning, continue improving and releasing. So straightforward, yet so elusive :)
Let's break it down -- this time, with rules!
- Generative user research for data is no different than any other kind of user research. Don't let anyone tell you that because there are numbers involved, all decisions about said data should be made through statistics or A/B testing. Tips for doing user research is covered elsewhere on the internet, and definitely feel free to wander around this repo to see examples of research plans, tools, and synthesis (check out the 'process' part of the subnav on this page). For a great (and short!) book on this subject, I love Erika Hall's Just Enough Research.
- Do not even think about starting work without the actual dataset you're going to be designing for. If you or your client cannot provide that, do not agree to timelines for any sort of finished product. Helpful language: "Every day my team can't access that dataset will result an equal slip on our launch date." It is true, and tends to get attention. Do you know how many times the mock data turns out to look like the delivered data? Zero times. That's how many. And you just wasted valuable time and effort designing for zero kinds of actual data.
- But! A subset of the actual data is pretty ok. Data folks are often worried about giving you any access to any data that might be a little bit not finished, or not fully approved. Invest the time in the conversations with folks so they understand that sample data to play with is great and the best and you love them for it. Later, when you add data tests to catch the things that machines are good at, leaving them to focus on more human-type work, everyone will be best friends.
- Before you can make a great data visualization, your team needs to fully understand the data. The best way to understand the data is to play with it. Start by munging that data into something your team can have a good discussion about. This might mean doing something as simple as putting a smaller dataset into Google sheets and generating a few tables to learn about max and min values, or something as complex as getting your more dev-oriented teammates to use D3 to create some charts. Sometimes this feels like a distraction -- why are we "wasting" time making something that won't be on the finished site? But it is not wasted! Pull that work up on a shared screen, and start talk through what it means. You'll find plenty of questions that need to be answered in order to create a clear and truthful design.
- Write! Use sentences! Never underestimate the power of sentences. Take a look at that generative research. Pull some of the problems you're trying to solve for into a shared Google doc. Pull some of that data prototyping in. Translate the thing that was meant for robots (a huge dataset) into something meant for humans (data, visualized and explained). Here's an example of an early discussion/prototyping page when our team was trying to put together a state profile page. We made several of these for several example states, with real data from our datasets. In the examples below, you're seeing Utah. This helped us catch our assumptions about the data, and understand what we could and couldn't display across 50 very different states of information. As humans, we want to design for the most complete dataset. In reality, most datasets are full of holes, and our design needs to explain and account for that. This prototyping work eventually became our state profile pages.
- Once you think you've got a data communication idea, build it! Perhaps even run a design studio to brainstorm ideas! But...
- Only build what is strictly necessary to take the next step. Your goal is not to build a finished product, but to learn enough to go back to the drawing board and resolve any issues that your testing reveals. Because you're absolutely not going to get it right the first, second, or even third time. Nope, you're not. And that's OK! Here's an early research plan from testing our ideas about state profile pages. And here's an early build of that page:
- Prioritize your build to test your riskiest assumptions. Not sure what to build first? Focus on this ideas that you're not sure about that will cause the most problems if you're wrong.
- Never skip retro. Ever. Even if it feels like your team is going along just great. Here's a suggested retro technique. If you're not already holding retros once a sprint, go ahead, get started :)
- Be wary of any team that wants designers to work separately from developers. Watch out for words like 'handoff'.
- Think about maintenance. What does your data pipeline look like? Can you suggest content that pulls from data rather than needs to be special-snowflake written and updated across the site?
- As you learn, you'll learn how to structure the data pipeline, too. This process is how you understand how your data could be pulled in and organized to best support what you want to support, and not be over-engineered to support use cases that you don't need.
Bonus section! Some screenshots from the site design as of May 1, 2017.
