Designing with purpose from the ground up. Passive documentation.
When creating digital products & prototypes, should we try thinking about every thing being a part of a list that cascades.
When adding anything to a digital product - think - does this add, populate, update or remove a row to a database? Does it add an attribute to that row? What is every other row that row relates to?
The idea being, perhaps it could be good to think about designing digital products from a database point of view. This may help inform leadership, finance, engineers, strategy, etc on what is actually happening, what is viable, and how the entire business architecture is being affected by a proposed design or update to one.
I feel like the benefit of this might help augment a designer fighting for a design - showing exactly how the decisions are progressing the purpose of the product. (As sometimes it feels like we're making the thing they said they want, but when they see the thing, they say its not what they want.. therefore forcing them to say the thing they actually want - which is usually some dark pattern they don't want to come out and say they want out the gate.)
Perhaps simply labeling elements as we go along as "object can CRUD, CU, etc".
I'm just thinking about all of this because it seems that i'm always seeing or am involved in having to quickly create creating MVPs for products, then having to ship them. Then, because it was a scramble to get something out the door, we have to retroactively untangle and reconcile its constituent elements with other parts of the ecosystem in the company or other products it touches.
I'm thinking, if we could somehow abstract everything and stand back a little bit, we could either before (or after the fact) see what's happening with the product's architecture and that sort of view with a different lens could help drive decisions more efficiently going forward (or from the get go).
You've read about SuperLabels. But what about SuperObjects?
Its like we're brainstorming without considering what's right in front of us. I.e demand sources and their constituents, business OKRs, and other current more business-y parameters.
Can we tie CRUD operations to every "object" in order to see how it affects everything else, data tables, other UI etc?
For example: Does object (x) EXPAND, or CONTRACT list (x).
For instance: a call to action button would either
expand list (x) in the same view (i.e. a dropdown)
exand the list in a different view (link to child or separate page)
contract the list (filter pill/tab)
Being strict about documenting what UI artifacts are parents/children of what - could help keep everything tidy when doing postmortems, or looking at iterating designs forward, or just understanding what's going on under the hood - (without looking under the hood so to speak).
