Designing for flexibility (or: users find a way)

I spend a lot of time thinking about "practical knowledge." Or, a slight variation, how different forms of practice or participation in a system yield differential access to certain knowledge about a system.

One category of knowledge on my mind lately is the understanding of edge cases when users of software are given some degree of flexibility: for example, allowing input on a front end that may be invalid downstream, open ended questions asking for freeform text, an on-page chat interaction to ask for help.

During the 6 years I spent working on GetCalFresh - but particularly in the early years of rapid iteration and high-touch concierging issues people had trying to apply for food stamps through the service - I came upon many examples of unexpected user behavior. Perhaps even beyond "unexpected" and into the category of what I might call "wat."

In the early days, I remember fondly returning to a phrase time and again - users find a way. Provided even a modicum of space for novel behavior, users would interact with our service in incredibly unexpected ways.

A few examples of unexpected user behavior I have seen first-hand, in the wild:

• A user somehow successfully using our web site to apply for food stamps on a video game console browser (if I recall, it was some generation of XBox)
• A user entering their name, character by character, in individual-letter emoji rather than letters themselves
• A user who uploaded a single document attached to their application: it was an audio file in a file format I had never seen of their own voice saying "I don't have any documents to submit" (upon investigation, I think we discovered that this format came from a particular flavor of Android phone prompting an option to record audio at a file upload point)
• Contra a very fundamental administrative premise of how food stamps work in California (that they are administered at the county-level) many different instances of people putting in an incorrect county for their city/zip code

...and many other examples I can't recall at this early morning hour.

(I would be remiss here if I did not link to the delightful and evergreen Falsehoods programmers believe about names by Patrick McKenzie/patio11 as a classic in a similar vein.)

Now the first few examples above might seem like completely reasonable edge cases that, if impossible, would create a tiny hassle for some people, but maybe not major problems. The last one - county mismatch with city - is potentially a much more significant insight: for me at least, having seen that case (and having figured out how to fix it for people manually prior to submitting it to the correct county) gave me re-anchored me in a very positive way.

Whereas the most obvious way to design this series of questions was to start right there up front with asking "what county do you live in?" I now had much more texture on the really existing spectrum of user processing of that question. That led to some very different design approaches over time; approaches that would have never been considered without (1) the initial flexibility for users to signal to us that processing information via their behavior and (2) an active process for investigating and fixing corner cases like this.

What am I getting at here? Designing software to be flexible specifically in the sense that users can do annoying things you do not anticipate is a window into the actual domain you are building in that should not be undervalued.

To get less abstract, I have found a huge amount of learning value myself in things like:

• Minimizing form field validation in the early stages of a service (accept accents characters! accept emoji! accept damn near anything!) even if downstream that form data needs to go into a more restrictive database (say, a legacy system with character limits or intolerant of accent marks)
• Having open ended questions like "is there anything else we didn't ask you think is relevant?"
• Building in "escape hatches" at critical points where the default path might be an uncomfortable pushing of a user down some direction, but you allow them to pull the rip cord and say it's not working for them in some way (say, a terms of service that you suspect might be scary to users in its legalese - you could have an explicit button or way to reach out, offering it if the user is confused or overwhelmed)

These examples are grounded in a multi-page web form style service, but I would like to be explicit this concept - design in flexibility, to let users tell you what you don't know - doesn't solely apply to online or software services. Think about a paper form that might say: "Confused? Overwhelmed? Give us a call here."

The other side of this is a big tradeoff: automation. What makes software a peculiar material is that it can scale and automate things so effectively. The more flexibility you build in, the less automation you potentially have. Infinite flexibility, for example - just narrate your situation and we'll fill out the form for you - is virtually unscaleable. And, huh, what does that "infinite flexibility" sound like? It sounds a lot like a direct service provided by an individual! Much of the really-existing use of technology is framed in the vein of self-service - definitionally designing something to take on the burden of some direct service for efficiency and other goals. (None of this is intended as judgment, but rather description. There are many reasonable points on this spectrum of flexibility in design based on the constraints of the system in which a serve exists.)

The primary thing - the "odd bit of tacit knowledge" here - that I'm trying to share is this relationship between intentionally flexible design providing this window into aspects of reality that very few others will have.

If you have fun examples of wat user behavior, send me a little note!

This post - like all posts here - represents my personal views and experiences, and not those of any employer or affiliated organization past, present, or future.