Regardless of party affiliation (none for me, thanks), no one should have been surprised by the recent Democratic debacle in Iowa.
I’m happy to see that mainstream media is finally starting to pick up on the reality that our fetishization of technology may not be the healthiest thing for either an egalitarian or democratic society. Several outlets did a great job digging into the root causes of the caucus reporting breakdown. Turns out, there’s an app for that.
And where there’s an app, there’s going to be Kool-aid. In this case, the Kool-aid was served up by Democratic Party officials who insisted the caucus app was going to be a-okay. Given that it ended up resoundingly not okay, perhaps it’s worth taking note of a few lessons we can apply in our own digital day-to-day.
Set realistic timelines.
According to the caucus app maker’s CEO, the team “basically had the month of August, September, October, November, and December to do it.” Five months from start to finish (or two, according to some reports) is not a realistic timeline for an app of this import. It’s probably not even a realistic timeline for your organization’s app. Developing a barebones app requires at minimum: requirements gathering, design, systems architecture, coding, QA, user testing, and roll-out. That’s leaving out a lot of other stuff (like proper discovery and user research before requirements are defined, soft/beta/alpha launches, etc.). And before any of you get on me about where content strategy is in that list, take a guess—that’s right: it happens throughout all of those phases. The timeline for the caucus app was so tight that they couldn’t even spare the 2-14 days it takes to get approved for Apple’s App Store.
So what’s a realistic timeline? That will depend (sorrynotsorry!) on your staff capacity, skills, and expertise. And it will depend on your budget. For an intentional, useful, well-built, single-purpose app or major website overhaul, you should give yourself a solid year. If you have lots of opinionated stakeholders, possibly longer. Seem crazy? That’s how long it took the team that built 2016’s caucus app—you know, the one that worked.
Research and embrace your users’ context.
Had 2020 officials done their due diligence, they might have made a simple phone call to Rodney Guzman, whose firm produced that successful 2016 caucus app. That conversation surely would have revealed a number of useful insights, such as the fact that many precincts ended up reporting results by phone, despite having been trained on the app well ahead of time.
We could interpret this little nugget about 2016’s telephone usage as a failure of app adoption. But that would be short-sighted. The reality is that Guzman’s team discovered they were working with two very different user groups: those with smartphones and great cellular coverage, and those without. And how did he discover this? By “doing usability studies to anticipate precinct chairs’ needs.” Go figure. Guzman’s team learned that for one group, the app was simply not going to be useful, however well-designed it might be. So they also provided an automated phone line dedicated only to reporting results. Two different technological solutions for two different user groups.
Our 2020 caucus app developers (yes, their company name really is Shadow and yes, Dems deliberately kept them a secret in the run-up to the caucus—more on that later), clearly didn’t do much early research. Sure, they provided a phone line, too (so…points?), but it was used for both tech support and precinct reporting. And manned by people. Not nearly enough people. A few simple conversations would almost certainly have revealed this make-or-break information about precinct limitations. And it really can be as simple as a few conversations (especially when time is tight).
Think about all the people who might have skin in the game when it comes to your digital project—not just your website visitors or app users, but content authors, development, your IT department, your Board of Directors. Any of these folks can stop a design project dead in its tracks, so talk to them early, before you start designing. Your learnings will seed your requirements—and may even lead to the discovery that perhaps an app isn’t the best solution.
Test, test, test.
Digital projects are built on dependencies, workarounds, and tied-together components. Even a system that appears to work in the lab needs to be tested in the field. The lab environment can rarely replicate the full context of the real-world scenario your app or website will be used in. Systems need to be stress-tested. Teams need multiple cycles of continuous improvement to ensure basic functionality actually functions. 2016’s Guzman again: “You cannot make a stable platform in two months. We needed that much time just to test everything. If they really did that, then whoever the management was in that company set their engineers up to fail.”
Who should test your digital product before launch? Start internally, with staff. You should have specific acceptance criteria clearly articulated, so staff knows what to look for. Then try it with a limited group of folks among your target audience. You can call it a beta, a pilot, or early access—just don’t call it late for launch. Incremental roll-out will help you catch the show-stoppers early and limit the number of users who experience serious issues.
Remember, though: there’s a difference between a bug and an enhancement. Focus first on what needs to work for a user to accomplish their task, but doesn’t. Then worry about the “I wish it were doing this instead of that” requests. It’s easy to bloat timelines when you don’t have a documented system for prioritizing feedback—especially feedback coming in from the executive director’s cousin’s nephew at the eleventh hour.
Don’t naysay your naysayers.
“According to a person familiar with the app,” reports the New York Times, “its creators had repeatedly questioned the need to keep it secret, especially from the Iowa precincts where it would be used…there were concerns that the app would malfunction in areas with poor connectivity, or because of high bandwidth use, such as when many people tried to use it at the same time.”
So just to clarify: party organizers did know in advance that this stuff might go sideways and they chose to hide the warnings instead of solve for them. Look, it’s very hard to deliver bad news or ask tough questions without throwing people’s hackles out of whack. Lord knows, I’ve pissed off enough product managers and bosses over the years with my truth-telling and hole-poking. This is especially true once the train has left the station. But whether they’re in-house hires or contractors, when someone on your team raises a red flag about basic functionality that absolutely must work, it’s totally inappropriate to ask them to please quietly fold up their flag and place it behind the tin of Shhhhut the hell up! on the shelf, so it won’t rudely wave potential failure in your face. You can teach your team to be diplomatic on the side. Right now, you should listen up. Few problems are solved by ignoring them.
If we look back at the sequencing of these lessons, it’s pretty plain to see that the Democratic caucus was a perfect example of how a single poor decision at the outset of a digital project can snowball itself into an avalanche. As the project continues, that first poor choice smothers every other downhill decision in its path. Yes, it can be hard to make good strategic decisions. It can feel risky. It might even push your timeline out. But that’s certainly preferable to cleaning up the Democratic Party’s Iowan-sized mess, no?
Get in early…
This post was originally sent to subscribers of my semi-regular email update. It’s safely occasional (like a sundae). Join us!