Well, no. Not exactly. But bad product development practices did. Maybe. Or maybe not; according to some, the sky is falling and according to others, it's just taking a minute to double-check results for consistency, or else everything is fine, or maybe not...
But, either way it is a lesson in product development...
Why did they use a smartphone app?
Politics laid aside, the DNC wanted to use an app to do their Caucus voting because it should be quicker and more trustworthy than the 2016 method of literally flipping a coin to allocate a delegate's vote because they couldn't be located. The problem statement is pretty clear. It is definitely a bad process in need of a solution.
Going straight to "We should make an app!" is super logical today - nearly anything I can think of, I can find an app for. But, good product design would have, should have, asked: Does it have to be an app?
Does it have to be an app?
Well, no. It's secure; that is good. But, it's hard to update if anything goes wrong. Plus, you have to make multiple versions for the different phones. You also have to support Phil from up the road who doesn't have a smartphone - so now you have to buy it for him, get him a data plan or install wifi in his house - the complexities add up. Good product design would have focused on the users and the very real truth that a web app would have been fine. And it would be easier to update if anything went wrong. And Phil could just pop down to the library to do it.
Challenge every assumption about what we think we need, and then design digital solutions that get out of the way and let us accomplish the goal.
Load Testing to avoid disasters
It's not hard to do load testing. It's costly, but it's not hard. When your entire product is designed to work for a ton of people all at once, but then never to be used again, you absolutely have to perform load testing. There's no way around it. I'm not saying they didn't do it, because I don't know. But if they did, then either the results weren't acted upon or else the remediation wasn't also tested. This is common. When you test a product for scale (or for security), you have to do it multiple times – how many times depends on a variety of factors. You test performance over and over because every time you fix one performance problem, you place the remaining load on some other part of the software, which may or may not be up to the challenge.
For example: Say you made a hypothetical app for, I dunno, voting. The basic system would be to present several choices to the user. The user taps one, the phone prompts them to confirm: You selected Jason's World-Famous Apple Pie as Best-In-Show. Is this correct? The app hasn't sent any data anywhere yet. All of the computation is on the phone. So far so good. Phones usually perform pretty well – even Phil's loaner phone. Then the user confirms the prompt. Once the user confirms it, the data is sent off to some cloud server someplace, data is moved around, stored, aggregated, etc.
Performance problems could happen anywhere in there. Maybe there's only 3G connectivity and it's a foggy day. If you alleviate the 3G problem, you make more requests happen at once. So, now maybe the API can't handle that many requests. So, maybe you enable Elastic growth (Thank you AWS...we love you for this). Now you can handle the requests, but can your reporting aggregations keep up? See, eliminating performance bottlenecks just moves the problem down the line until finally, you eliminate enough problems to make the product viable.
Piloting as a safety check
Something as important as a federal election probably needs a pilot program, at the same scale as the real thing. Something with low stakes, nationwide so you know the limits...I would have happily participated in a Vote for your Favorite Sandwich pilot, if it meant ensuring a smooth rollout at the Iowa Caucus. There are always kinks in a new product. Always. I have never seen a rollout that didn't have at least one kink – I thought I did once, but it turned out I needed to wait like 30 seconds longer.
Digitizing a complex process does not ensure success.
This is the biggest lesson here: Digitizing a complex process does not ensure success. Period.
The Caucus system is old and made sense once. But reading about it today - to ensure I understood it - took more than 6 paragraphs to explain it, and I still don't really get it. It is a complex system that made sense when it was instituted. Making an app that simply replicates the system doesn't fix the problem. It makes it worse. It adds authentication, logging, support, phones, wireless carriers, SSLs, support staff, demands for immediate results, reporting solutions and costs, etc. It's complexity on top of complexity. Good product design should have caught this and demanded a change in the process itself.
Digital Transformation doesn't mean "Do everything digital". It means that we challenge every assumption about what we think we need, and then design digital solutions that get out of the way and let us accomplish the goal.
The Budget Matters
According to The Wall Street Journal, this app cost $63,000. That's a really low budget, and it would be surprising if adequate load testing or QA happened; the tools and time simply cost too much. Rigorous testing couldn't be done. As the old adage goes, you get what you pay for. Adding to this, Nevada paid $58,000 for a similar system; don't be surprised if we see similar results. Not saying it's certain, but let's not be surprised.
Understanding Your Users
Real product development thinkers understand that 'user experience' encompasses the entire system – not just the buttons that you tap. Reading about this "App failure" is really interesting. Some of the biggest failures here are not understanding the low tech audience, not training people to be able to easily download and use the app, and trouble logging in -- tech issues aside that's a frustrating list of misses.
Takeaway
How is all this a lesson in product design? Well, each of these points above is basically critical to the process. Does the problem really exist? Does the solution match the problem or is there a better one? Does it need to pilot; or How will this get rolled out? What are the consequences of failure? Are we making it as simple as possible for our users or are we simply passing on the complexity? Is this app going to hit the mark with our users? Have we made any baseless assumptions about our users?
Based on what I'm seeing in the news, one or more of these critical questions got missed. And that's really unfortunate when the stakes are so high.
