Lady UX Diaries: Engineers Have Been Building Software All Wrong (Part II).
Today, let’s consider the concept of polite software. If you missed out on Part I of my Lady UX Diaries series geared towards software engineers in the build and design hamster wheel, go back here and get caught up.
But yes, I said polite software.
Let’s first consider the screenshot below. These should seem very familiar to you as both a user and a builder of things:
Have you ever stopped to ask why you are being asked this question after you clearly meant to delete something?
When was the last time you decided to delete an item and this window actually changed your mind? Something like: “Oh shit, you know what, I didn’t mean to delete that actually. Thank goodness for this pop-up window!”
Said no-one ever.
So why do we design software to do such things? Things that irritate us as consumers, belittle us, and sometimes make us wonder why they exist in the first place?
Most software designed when using software programs became a thing (I vaguely remember software popping into my life around eight years old, and my mother sitting at her Windows 98 machine cursing it repeatedly for this new thing she had to learn that wasn’t a typewriter) didn’t know nor did it care who was using it. You could argue it is still that way- none of the software I use on a daily basis seem to care about me, anything about me, or how I operate.
Consider things like this that might seem small and inconsequential. I am very picky about fonts that I use when I write. For some reason, Times New Roman gives me writer’s block. So one of the first things I do when I open a new doc on my work computer is change the font to our internal Google Sans font, which I absolutely adore, and gives me feels as I start writing. I also size the font smaller (11 pt) and change it to a slightly lighter grey to soften the look of black font against a white doc background. These things I do every time, whether it be at the start of a new document or when I copy and paste text from elsewhere.
Why doesn’t Google Docs remember this about me? The relationship has been extensive now, and at work I have been going through this ritual for over a year.
Consider the screenshot above, asking the user if they are absolutely sure they want to delete the thing they clearly just selected for deletion.
Why is software so impolite to ask so many annoying questions?
Doesn’t software know that humans actually don’t really enjoy choices, and in fact view them as an ordeal versus a benefit?
One of the reasons this might be per Alan Cooper in his awesome book The Inmates Are Running the Asylum is actually the engineers behind these little nuance “features” if you were who built them years and years ago, when software was first a thing to build.
Computer programs are procedural, and procedures maps closely to features we engineer into the flow of our code. It was only natural back then that programmers would be the humans to define what precision and correctness meant, all the way down to dictating exactly how the consumer’s workflow would look like.
Human workflow has typically been interpreted as a list of features in succession, with a clean programmatic trigger here to bring this popup to prompt there, with little to no consideration given towards the human on the other end of the software who is trying to comb through hundreds of photos and delete the ones they don’t care for after a long and irritating family vacation.
Consider another process we are all too familiar with- downloading and installing programs from the internet.
Have you, as a builder of things, ever paused to ask yourself why we force consumers to download programs from the internet this way? What is to say this process shouldn’t be completely invisible to the user? Once “download” is clicked, the program seamlessly downloads in the background, with no prompts to move the program to the Applications folder after completion.
What if desired user actions just… happened. Without questions?
The only reason why non-browser programs require the installation process is… well, because that is how programmers have built this process since the beginning of time.
So, what is polite software?
Consider the list Cooper poses in his book:
- Polite software is interested in me.
- Polite software is deferential to me.
- Polite software is forthcoming.
- Polite software has common sense.
- Polite software anticipates my needs
- Polite software is responsive
- Polite software is taciturn about its personal problems
- Polite software is well informed
- Polite software is perceptive
- Polite software is self-confident
- Polite software stays focused
- Polite software is fudgable
- Polite software gives instant gratification
- Polite software is trustworthy
When considering this list as a builder of things, part of it made me shudder with disgust (“who does this entitled consumer/user think they are?! Suck it up and use the software, dammit!”) but then I realized that in considering this list (ACTUALLY taking the time to go over the list) challenged me to re-think the whole software design and building process altogether.
And there is something thrillingly challenging about the idea of being able to do that. Change how software design and building is done, period.
We have gone through our frenzy of building cool apps, branching off startups from apps. When is someone going to revolutionize the way we do regular, everyday, non-sexy workflows like editing documents and installing programs from the internet? Could these actions be re-engineered to make humans more happyproductiveselfcontentcreative?
Enough complaining, what is the solution?
So we will get the first obvious point out of the way. Put design before programming, and change the software development process.
One who manages teams of people (mostly engineers but maybe includes some UI/UX professionals) might look at this and think- oh shit my engineers are going to kill me.
Yes, they probably will want to initially. There is a very interesting downward spiral with very talented engineers that start with a perceived threat on the engineer’s end, then cascading into a conversation that is filled with passive aggressive remarks, ending with passive aggressive engineering actions that can be seen in a code base build (maybe that’s how we got the word “Submit” as one of the options for a user completing a software action…).
I always come to the point of changing the status quo and how things have been done in the past, which is a painful process for engineers not because they cannot adapt to change quickly (they are in the most rapidly changing career field known to man, for heavens sakes).
It is oftentimes painful for engineers to change how things have always been built, I have noticed, due to their deep desire to build things the right way. Deviating from known successful ways to build software might lead to software that breaks, which is catastrophic for a builder of things.
The solution proposed by Cooper in his book (which still makes me feel queasy, but remember, put all previous opinions and assumptions aside and consider for a minute) is twofold.
- The designers need to write, storyboard, animate, and sketch their solutions with completeness and detail. Provide programmers with blueprints that code can actually be written from that is written to the end-user of the thing.
- Designers design for a year, programmers build for a month.
If you are a developer, number two sounds horrific. But consider the following things that would/could happen if these two aspects were implemented:
- Programmers would be focused on building. Not pontificating on the build, not philosophizing on how feature X is built over feature Y. An environment of rapid hustle would develop. Under pressure and limited time, humans can produce some incredibly innovative ways to solve problems that might seem lazy, but at the end of the day actually make a process ten times more efficient than if they had had time to over-analyze each task the program must accomplish.
- The programming team would be presented with the ultimate challenge- build exactly what the design team has asked for, even if its not worded in a flow of features. No more copying and pasting of code from previous builds that accomplish a task that would equate as similar in a programmer’s head. But start from zero, re-imagine the process, and produce it. Fast.
- Programmers would stop testing their code. That’s right. Hand the testing over to the actual Q/A testers, who actually enjoy (or have been forced to by their inability to change their career destiny) testing code.
So with the considerations laid out here, and the solutions proposed…
What are you waiting for? Go build polite software and revolutionize how millions of humans do regular things everyday, and forever be remembered as the dev that changed how files are deleted from a user’s system!
