Lessons in #UX: How to avoid the #UXFail that was the Iowa Caucus

I’m an apolitical person, and have described myself as an “Independent Libertarian.” I don’t want government in my bedroom or my wallet, and am a strong advocate for individual freedom and personal responsibility. I pay more attention to geeky and tech matters than political news, but as the upcoming presidential election begins to creep closer I have to take note of what is going on.

And yesterday, what was going on in Iowa for the Democratic party was a hot mess.

To recap: The first caucus in the process to assign delegates in the race for the Democratic nomination ended with… No results. There were multiple reasons given, but the primary one was an “issue with the app.” Only now, almost a day later, are partial results being provided to the public.

Said app was developed by a private company, apparently in isolation, over the past two months. It was not tested, it did not scale, and the caucus workers using it (mostly volunteers( received no training on said application.

As I often state (quoting – supposedly – Mark Twain): History don’t repeat, but it sure does rhyme. I had previously written about the failures of Mitt Romney team’s ORCA election day app in 2012. Yesterday’s #UXFail shared a lot of similarities to that situation.

The impact of this mess, and how it will affect the selection of a nominee, is still to be determined. But if this article has any credibility, then the nomination process is profoundly effected.

So in the interest of helping you and your organization avoid similar “egg-on-face” moments in the future, here’s some advice to avoid this:

Identify when an app is “mission critical”

The level of effort and due diligence that a design and a development team expends on an app should be directly proportionate to the importance of said app. An application that transmits real-time medical records for a patient in ICU needs a lot more QA and user experience work than an app to, say, add cartoon noses to selfies. You consider the former a “mission critical” app.

To me, “mission critical” means exactly what it says – If the app does not work the “mission” cannot be accomplished. Like saving a life. Or counting caucus votes.

While I was not a part of the team that built the vote-counting application used in the Iowa caucus, from the outside it looks like the proper level of effort that a “mission critical” app required.

Have full accountability and responsibility

But who makes that call? Usually it is the product owner, the person who is the “single throat to choke”. He or she pushes for an negotiates the resources and efforts required. From what I’m reading in the news, the company that produced this app has… Ghosted. The office they listed in the filing paperwork in Iowa is empty. Now are there lots of screaming and yelling going on in DNC offices right now? I’m sure. Have they identified where the responsibility lies? I hope so.

If you are the product owner, it’s on you. You may not be the person coding or testing the app, but you have to own it – The good and the bad.

Test, test, and then test some more

This covers both QA AND user experience testing. Test scalability, test usability, test data integrity and quality. This is the “Well, DUH” section of this piece, but I would be remiss if I did not note it. Quality matters, and you ensure quality through rigorous testing – even more so for an application like this.

Don’t hide behind the “MVP” excuse

I’m seeing some media columns blaming the agile software process and the idea of the “minimal viable product” for what happened in Iowa, and such criticism deflects from the responsibility that lies with the ownership and implementation of an effective MVP application. The idea behind an MVP is toi make sure that the core functionality that is absolutely necessary is there – not that is built in a slapdash fashion. Some pundits and journalists should, quite frankly, learn to code.

Train users (and do trial-runs)

So many organizations think that people can just “figure out” applications. And, yes… applying a version of the pareto principle, 80% of users can work through apps on their own with no help. But this type of notion is just a single dimension, and it’s an uneven distribution based on who the users are.

You can say that about, say, more tech-savvy millennial… But what is the average age of the caucus workers using this app? I’d wager it’s 47. A classic principle of user experience design is to “know your users”… And a simple survey would have informed any roll-out decisions to make sure the proper level of training and support was provided.

“OK Boomer, here’s the app to enter the results. Good luck!” was not the right approach.

And also, do dry runs. Let the end users test and use the app when there are no negative4 consequences. When if you screw up, there is no impact. I don’t know if they did this or not, but I’d wager not.

Continuously backup to the cloud

If there were “discrepancies” in the data, this is an easy way to resolve it: In the background, continuously upload and time-stamp the data to ensure that the numbers have an audit trail and can be reviewed. Maybe this happened, but… I’m seeing no indication that such a “backup plan” was in place.

Don’t over-engineer a solution

As some people online have already stated, the counting of the caucus votes could have been done in an Excel spreadsheet in the Cloud. Or even with paper ballots and ledgers. Of course, that is the simple straightforward solutions that make the most sense. So, of course, they didn’t do that.

The cliché “Keep it simple, stupid” is a truism for a lot of reasons, and this is a textbook example of why that is so. The process of using the app was overly complicated, and there were a lot of ways that things could have failed – the main one being, simple connectivity. If the app can’t connect to the Internet, could it even work? Was it a compiled installed app or a URL? What I’m seeing leads me to think it was more the second type of app than the first.

Have the right team

App development is not easy, and with apps such as this an organization should NEVER rely on any fly-by-night startup. There are HUNDREDS of software development shops with rigorous software processes and quality standards – And yes, they will be more expensive. But when you look at the “bearing cost” a reputation hit such as this brings, with a big part of the nation watching…

Well, spend the money.

UPDATE and POSTSCRIPT: This Twitter thread about how campaign apps are funded and made puts an exclamation mark on my last point.

Comments are closed.