Can acceptable user interfaces be derived from the schema of the data that powers an application?
New application design typically means producing a visual representation (wireframes, mockups, clickable prototypes) of UI and UX that serves as a design specification for the subsequent development phase.
There are two major problems with the typical approach:
As development evolves, the product increasingly deviates from the design, meaning there’s no longer a definitive specification that product owners, developers, designers, QA, etc. can use for a shared understanding of the product.
One symptom of this problem is that there isn’t a single consistent and precise notion of the product that can be used in instrumenting for analytics (reasoning about the production system for business and technical purposes). The team may lack a common language for referring to the various screens, components, features, etc. involved in the UI, making it hard to map analytics events back to specific behaviors the user executed in the product.
Turing award-winner and distributed systems expert Leslie Lamport describes the problem of building a house without blueprints. Too often in front-end engineering we rely on the software equivalent of a scale model instead of a blueprint.
The typical visual formats (wireframes, mockups, clickable prototypes) encourage the team to think about details of the UI that aren't critical to early user acceptance. Much effort goes into decisions about layout, navigation, aesthetics, and many other issues that may not improve user experience.
As an example, consider a team deciding between whether (a) the user composes a new message within the visual context of the message thread, or (b) the user is taken to a different screen for composing new messages. In my experience with early-stage development, this kind of design issue can be a source of lot of lateral movement in the project - debates among the team, prototyping it one way and then the other way - that cost valuable time. Often the right answer isn’t knowable without user testing.The problem is compounded by the extent to which design decisions are highly coupled with the user environment. The right answer varies with screen-size: perhaps (a) is right for desktop while (b) is right for smartphone.
Ideally the initial design would deal with this issue at a higher level: “users must be able to compose new messages” and leave the rest to platform-specific implementation.
Let’s consider a different approach that solves these problems and has the potential for big gains in speed to implement, quality, and malleability of the resulting application.
Similar to the first step in the traditional approach, design begins with product owner, developer, and designer working together to get the product vision out of the owners’ heads and into a visual representation of the UI and UX. The Product Design Sprint process as described by Thoughbot provides a good overview of the considerations involved in this step.
The difference here is that this step needn’t have all of rigor required when the goal is to produce a requirements specification. The team can deal with a high-level representation of the product's user experience and work quickly by deferring details. While digital tools like Invision can be used, whiteboard, pen/paper, simple wireframes should be sufficient.
Using the output of Step 1 as a guide, the team works together to produce a functional software design specification for the data that drives the system. I propose that two data-description formats are sufficient as a design specification from which to infer functionally conformative UI variations: Conceptual Schema and User and System Events.
Let’s consider an example of a basic text and photo messaging app which uses an algorithm to emphasize the most important messages.
These two design formats should be familiar:
Drawing upon existing precedents such as Active Record model view/edit UI scaffolding and incorporating proven UI design patterns, middleware can be created that rapidly generates UI components and layout variations that conform to the rules. The team can evaluate these variations and make initial choices for initial testing with early users. Initial UI choices can potentially be customized based on the feedback from this testing.
This approach assumes that for a certain significant class of applications (new development, CRUD-heavy, basic UI requirements), product owners are better served by selecting from a set of arbitrary application UI variations that conform to all relevant constraints as stated in the formats above.