When Apple first released the iPhone, the company did something that was a bit wild, a bit innovative, especially for a new piece of technology. The iPhone did not come with a 500-page instruction manual explaining how everything worked.
There was very little documentation for users. Apple worked hard designing the interface to allow users to apply their own intuitions and navigate around. While some grumbled, it was successful enough, and people adapted.
Now, we are increasingly presented with technological mini-miracles, low-code/no-code, large language models, and generative AI instantiating results that can amaze. In the face of all this wonder, it is easy for one to become lazy or jaded and simply assume that little effort is needed. Just because one may relate easily to the tools they use, that ease of building does not mean one’s output is self-evident and easily consumed by all end users.
Such an assumed cavalier attitude is inappropriate. Effort and thought must always be expended in addressing how others may relate to your data models or user interfaces. And easy-to-use solutions are not necessarily simple or easy to assemble. Establishing easy-to-read data models or easy-to-navigate applications involves quite a bit of work from those who create the tools presenting the “easy answers.”
Designers need to understand how people think, perceive, and relate. Integrating these squishier aspects into a design can cause headaches.
Many data models throw away useful meaning by entertaining developers’ often misplaced perceptions of decode tables. The data modeler agrees to establish a single code table allowing any and every code into one monster table.
Then this “one ring to rule them all” table is used for every process to verify values or create drop-down lists for screens. The savings in such an approach is that the DBA executes fewer TABLE CREATE statements, and maybe the developers have more reusable code elements. However, if instead, specific code domain reference tables were instantiated, then verification of the validity of a code value could be handled automatically by the database. True, more tables would now need to be physically created, but users could directly look up and see the valid values. This is as opposed to having only one table and then trying to track down the code type value identifying the set of values in which they are interested. (This is assuming a decode reference table of those values actually was created.)
Additionally, if the related application does have drop-down lists of these values, with a separate and distinct reference table, more elements of that process might be automated. Either by establishing tables that are unions of many ideas, like the previously mentioned master code table, or by other inappropriate abstractions or denormalizations, users may end up with data models that do not answer their questions about the data. Under these circumstances, the answers are ultimately buried inside code that the questioner may not have access to. In 2011, Zack Snyder put out a movie called Sucker Punch. It was slightly controversial, but it ended with a quote I have always liked: “You’ve got all the weapons you need. Now fight!” It is a very reassuring statement: Don’t worry, you have everything you need, all you must do is the “apply yourself” part. When designing databases, interfaces, or apps, have we set up our intended users so that they have all they need? Have we merged what is presented and what we believe the users can intuit properly?
May users successfully fight through whatever their current business needs are? As designers of whichever flavor, that question of proper enablement is a question we must ask ourselves about our output all the time. Make sure your userbase always has the proper weapons it needs.