What UX Designers can Learn From the Iowa Caucus
Preamble: I can never understand the pressures and constraints the team that built the app for the Iowa caucus was under. I do not intend to shame the team or their work, only to share what I think we can all learn from the situation.
What happened?
Many armchair politicos (myself included) stayed up late on Monday to watch the results of the Iowa caucus roll in. Since 1974, 7 out of 10 candidates who’ve won the Iowa caucus, later secured the Democratic nomination. I reloaded Twitter repeatedly, anxiously waiting for the first signal of the 2020 primary season. And then, I gave up around 10 p.m. and went to sleep, figuring that when I woke up, I’d know who won. What I awoke to was instead that a mysterious “app” meant to relay all the results from 1600 precincts had failed to do its job, and the fallback plan of “good ol’ fashioned phone calls” had also fallen through. The blogosphere cried “cheating” and “outrage,” but all I could think was, “Jeez UX can learn from moments like this.”
Learnings for the rest of us
- Do less.
This happens to be my favorite UX principle. As a UXer you’re often asked to design an app or a screen or a feature. When you build a new feature, the design of the app is one piece of what makes a product functional. The app has to work, has to have limited bugs, has to be ready for the traffic it will get, has to not have security vulnerabilities. What would happen if you “did less” in this situation. What if you tried an existing product, like Google Sheets, as an MVP? Could you try something that builds on the backs of other teams and products before creating something new? - It might not be an edge case.
One of the rumored reasons the app failed is because some users did not have wifi at their precinct. First, is that really an edge case? Is it reasonable that a group of people across Iowa, may for whatever reason not have wifi in some situation? A site visit or survey can help you know more about what your users will experience. - Design for loading states.
What do you think users saw when they attempted to report their precinct’s results? Did they see a helpful loading message, that indicated the flaw and what to do? Did they have to rely on documentation to get out of the state? How does your product handle this “in-between” moment? When you send a result without wifi, could you design for a state that will store locally until you reconnect? What can you communicate to the user during a failure or in-between moment to assuage nerves? - Test your backup plan.
None of us are perfect, and sometimes you need your fallback plan. For the Iowa caucus, it was to manually call in the results. However, so many people called in, that the phone lines went down. Have someone not connected to the project test out your back-up plan and give you their thoughts. My UX Critiques are filled with “happy state” designs, and flows that are immaculate (if you follow exactly the steps prescribed in the prototype). My user calls are filled with customers who got backed into a corner, or did something out of order and now are faced with a confusing error message. Design and test for the failures, don’t test your happy state and give it a 100% for passing all the (moderated, prototype) user tests.
One last thing, we all fail. If when you fail, you can look at the situation rationally and identify learnings, you’ll feel much better about the process. It will make you a better designer and colleague to handle failures with grace.
Anybody else wanna talk political UX? Hit me up @chebathurst on twitter.