In my last post, I discussed how changing the environment could change people’s behavior. Further, I proposed that software tools are as much the environment as a developer’s office. Careful prompt design within those environments can create better behavioral outcomes with less effort and more buy-in. But what does that look like in practice?
The Stack Overflow Example
Stack Overflow is a website where people ask questions for other people to answer. To remain viable, Stack Overflow desires certain behaviors from its audience. First of all, they aren’t interested in quantity but quality; poorly worded, vague, or duplicate questions aren’t welcome. You don’t go to Stack Overflow to idly chat. Further, they aren’t interested in lots of answers, only the right answer.
The website’s environment goes to great lengths to prompt these sorts of behaviors. Before one is allowed to ask a question, a modal pop-up reminds the asker to search to see if their question has already been asked and how to ask if they can’t find a prior version.
If I, subsequently begin a question, the interface immediately provides feedback as to whether it is worth posting, and any already existing questions. The process continues through the post body, with a host of prompts for specificity, uniqueness, and completeness. By exhibiting these behaviors, I’m more likely to get my question answered, and the site gets a valuable reference for the next person.
Stack Overflow still has moderators. They do step in when necessary. But the amount of manual intervention they undertake is significantly less than if there were no environmental nudges toward behaviors beneficial for the community.
The OpenAPI Example
Likewise, we should think of templates also as a prompt. When capturing business intent in an API specification, like OpenAPI, many tools present a bare-bones template. This template exists to help a new designer get started but often it is the most minimal valid version.
There is so much potential here! Most companies I’m familiar with have some form of an API style guide. Imagine if I, as a new developer, had those desired API behaviors around naming, descriptions, and responses embedded in my tooling? How much easier would it be to design “the right way” if I just had to customize a relevant example rather than invent YAML whole cloth? How much more likely am I to adopt a particular error object structure if it is prompted at the beginning of every new design, as opposed to having to track it down in documentation somewhere else?
We’re not there yet with organization-level templates. And, even then, more meaningful templates for their toolchains are only the beginning. As Stack Overflow shows, there are numerous types and times for prompts in a software environment. As people trying to create better outcomes, we need to add environmental design to our available approaches.
