4.3 Towards Better Ux
I have no formal training on Ux development. There are whole courses on the subject taught at very fine design colleges, but I didn’t go to one. I do not have any real qualifications or certificates on the subject. I am not lean, six, nor sigma. But somebody on the team who made IPPS-A surely had some sort of a degree in design and look where that got us.
Aside from essentially a Photoshop 101 class in undergrad at Michigan State, everything I know is self-taught, based off my own experience in using and MacGuyering digital systems. I learned both from getting it wrong and a lot of fumbling through. I watched hours of YouTube and searched through Reddit forums, finding other people along the way with similar challenges. And I’ve spent 21 years being the victim of a lot of bad Ux. PowerPoint slide briefs are, in a way, just a failed Ux since you can’t interact with them. They are better used for art than for data.1
One of our principal problems is with the way we procure software. Jennifer Pahlka details ‘the waterfall’ process in her brilliant book Recoding America.2 Essentially, we contract for code the way we build tanks: step one is a long and detailed list of requirements that tells the vendor exactly what you need the tank to do. Once the requirements are set, they do not change, and an update restarts the entire process.
Except Ux design is not like this, because software isn’t. Ux is iterative, so stop trying to make it perfect the first time. You won’t. You can’t. It’ll move and change, and we’ll want new features, or to incorporate new systems into it. Because software can change in a way that a tank can’t. It’s just code.
Any new system is going to take some time to learn. This is part of the reason there’s so much resistance to change. Even if your new tool is going to make my day better, I have to spend time now on the bet your new system is going to pay off. And your new awesome Ux is running up against decades of army systems that didn’t pay off, so the pessimism you have to overcome is not unfounded.
It’s worth highlighting, who ‘you’ is in this case.
Up till now, my posts have been written for principally a soldier audience. With this one, I’m widening the aperture to include anyone writing code which soldiers use.
Now, just because I’m inviting in civilian coders doesn’t mean soldiers, and commanders, are off the hook. As I’ve detailed throughout Downrange Data, we built a lot of systems on our own, so for anyone else trying digital duct tape and bubble gum solutions, this should help. Learn from my mistakes.
More importantly, commander’s need to be involved in the systems their soldiers use. As anyone who went to Ranger School knows, you have lay down in the firing position, see what it’s really like, before you can emplace your team. If you don’t know what the Ux your soldiers are dealing with, you’re failing them as their commander.
Your goal is for a steep learning curve.3 If you do your job well, I should never have to go to a class or read a book to use your product. Ever take a class on Facebook? Remember that lengthy user manual you read before you started using your new phone? Nope, because good software shows you how to use it on its own. You accomplish this through some key design choices:
If you’re not the user, then damn well find the person who is.
This is the most important step, and it’s one you take before you even start to code. Go find the poor sod whose day you’re about to ruin, and instead find out how to make their day better.
The army typically screws this up because we treat commanders as the customers, not their staffs. Commanders will almost never actually use the system. There’s an expression called ‘dogfooding’ where you use your own Ux to do your job, so you understand where it’s not working well.
It’s a good practice, but in this case it’s an even better metaphor, because that’s how the army system currently works. Some senior leader buys the software, but never eats it. They have aides, and executive assistants, and staffs for that. So, while they’re enjoying their own personal chefs, you’re stuck eating dogfood.4
Stop making us learn a new vocabulary.
If you get with the actual user, you’re almost guaranteed you’ll get this step right. As much as possible, repurpose the words they’re already using.
IPPS-A went 180° the other direction when it switched ‘leave’ to ‘absence’, only to double down and then hide it all under ‘PAID’, which no one read as an acronym and assumed was tied to our pay. This is a small part of why so many units are still requiring additional paperwork outside of IPPS-A to process leave.
Wherever you can, use real words. ‘Pinch’, ‘Pin’, ‘Bookmark’, ‘Tweet’; all of those are words we stole from our existing vocabulary to describe digital processes. Real words for real things help us with the scaffolding we need to build the new mental models for the new digital world you’re designing.
You can try to just shorten the existing terms but be careful. Army acronyms are atrocious, and our 3-letter initialisms are an even worse infestation.5 The business world has its own acronyms and initialisms, but they tend to at least tell you what they are.
B2B, or business to business — a kind of sales.
RoI, or return on investment.
The idea behind this verbal trick is to streamline communication, saying less while still communicating the same amount of information.
Contrast this with the ones the army uses: POM, or Program Objective Memorandum. You know those three words, but I didn’t tell you anything by using them. FDU vs. CMP — Force Design Update and Change Management Plan. Those are basically the same thing — don’t @ me FA50s — but neither tells you what it is. If you can’t describe your Ux process to someone outside of your office without their eyes glazing over, go back and try again.
Make the work do the work.
This one can be hard with some tasks, but it’s the goal to aim for with any system you design. You want to seamlessly supplant your new Ux under the actual process each of your users is doing. We can’t make a system that assesses each soldier’s shot on a weapons qualification and automatically updates his personnel record — yet. But we can supplant the one his NCO is using to get that information uploaded.
Every step away from the ground truth is data loss. In many army systems there’s a ‘six degrees of Kevin Bacon’ from the person doing the thing to the soldier entering it into the database. This is how we got DTMS, which was so cumbersome that units couldn’t find time to both train and record the training. Instead, units created additional jobs on their staff where some poor soldier had to input data into DTMS all day. But that was data they had no connection to, so there was no understanding, no quality control. This was why the Army’s Chief of Staff hates on DTMS so much. It’s not because he’s anti-data, it’s because DTMS was costing him thousands of soldier hours just to get garbage data. The same could be said for Defense/SOFReady, IPPS-A, and until some relatively recent updates, DTS.6
‘It’s the Conjoined Triangle of Success’
7Good Ux design is not just ‘have fewer clicks’, though everyone hates a Ux that requires too many. 14 clicks are certainly too many when lives are on the line. This was exactly what 2nd Brigade Combat Team, 10th Mountain Division had to struggle through while trying to defend eight bases in Iraq and Syria. With seconds to execute tasks, their counter drone Ux desperately needed revisions.
But it’s the same in our PHA, which loads over fifty health questions one at a time on it’s own screen.8 Every soldier has to fill this out every year, which adds up to millions of lost hours.
There are cost benefits to design decisions, ones that can be visualized with a triangle. One leg is the number of clicks it takes to execute the task. The next is the amount of information displayed on the screen. The third is the time it takes to learn your new system. It's easy to picture the problem when any leg is too long, but as you shorten one leg you will often have to lengthen the other two.
You can reduce the Ux to a single click, but that often means a cluttered screen with random icons all over it.9 You can reduce the information displayed to a single item at a time, but then you get hundreds of clicks like in the PHA form. You can try can try to shrink the learning cost, but that comes at the constraint of the systems actually capabilities. So while you aim for less clicks, less search, and less training, understand those three have to be in balance.
Editing, agile, and the future
Just like with writing a paper, good code needs good editing. It’s not just a question of ‘does it compile?’ It’s a question of how users are flowing through the process. Did you use colors wrong or fail to take advantage of shapes and layouts that better tap into the users' existing heuristics? George Cave has a brilliant run down on how things like color, shape, and position impact Ux, all done through the lens of LEGO. Did you take into account the best way to display data? Perhaps most critically, did you ask me for information I already gave you? Because studies have shown asking users to repeat themselves leads to customers dropping off. Did you find a way to reward veteran users with shortcuts to help the processes they do most often?
You’re not done with your Ux when it ships. You’ve got to refine and adjust, keeping up both with customer needs and new advances.10 This is why the software on your phone gets updates all the time. Good software vendors are always working to improve the customer experience. Which might be part of why so much army software sucks: we the soldier aren’t treated like the customer.
But we should be. Human machine teaming was the DoD’s way forward over a decade ago. General Rainey, the head of Army Future’s Command, has stated the next military revolution will be ‘data centric warfare’, when we can link up all the sensor shooter webs. That’s going to take data, and it’s going to require a lot of iteration and integration between different software companies, something the Primes have thus far been unwilling to do. Want AI enabled tools? Then it’s going to take data.
A bad Ux is always going to give you bad data. But a good Ux does more than just give you the data you wanted, it brings the user — the ‘U’ in Ux — along with it. When you have data literate users who have been engaged with and involved in the process in the right way, they feel agency. They want to be part of the solution. They start asking, ‘Can you make it do…’
See my next post, 4.4: You all did love PowerPoint once, not without cause.
Of all the books I’ve suggested in this substack, this is the #1 must read of the list. Go get it. Now. The Secretary of the Air Force Frank Kendall agrees.
Wait, what?! Yep, I meant that. Turns out you’ve been using ‘learning curve’ wrong your whole life. The x-axis of a learning curve is the time it takes to pick up a new task. A steep learning curve describes something you learn quickly, while a flatter, longer curve is much slower. And now that is a thing you know, and you will never be able to hear someone use ‘learning curve’ the wrong way and not have it grate on your brain. You’re welcome.
Seriously, lots of US Army generals get their own chefs.
You can pronounce an acronym. Think ‘scuba’, or ‘NASA’, or ‘FUBAR’. Initialisms end up being spelled out: ‘RFO’, ‘PCS’, or my personal pet peeve: ‘IOT’ — which is just a 50% longer version of ‘to’.
Defense Travel System. The software service members have to use to book their travel. While it could still see some improvements, DTS has gotten better than it used to be. It only took <checks notes> 20 years. For comparison, that’s longer that the entire life cycle — design, launch, dominance, irrelevance, and end — of the iPod.
Not really, but I couldn’t resist a good Silicon Valley reference:
Periodic Health Assessments. A detailed questionnaire about your entire health history. It stems from a good idea, looking out for soldiers. Except every time you do it, the systems goes, ‘New year, who dis?’
See the title graphic on 4.2: Bax Ux = Bad Data.
On a recent episode of the Decoder but they verge, Nilay Patel and Davied Pierce discuss the challenges of productivity software. It’s well worth the listen, in particular to hear why Ux design choices led to people using Slack wrong.