What is User-Centered Design Process Entropy?
And how does Object-Oriented UX solve it?
User-centered design process entropy is when the fidelity and intended result of an iterative design process, degrades, gets lost, is misconstrued, or becomes disoriented due to the lack of a shared and intentionally constructed mental model.
User-centered design process entropy results in differing, inconsistent, and poorly communicated and coordinated mental models utilized across the multi-disciplinary user-centered design process. The consequences of process entropy include, but is not limited to:
- Design debt
- Technical debt
- Multiple unintentional and competing mental models
- Poor external communication with clients and stakeholders
- Poor communication within and across teams
Object-Oriented UX (#OOUX) borrows the object metaphor from object-oriented programming in order to coordinate and standardize the mental model used across disciplines and phases of the user-centered design process. Replacing a fragmented, atomized, and linear process with an integrated and holistic approach provides increased opportunities for collaboration and efficient cross-team communications.
The possibilities for “OOUX thinking” are numerous and multifaceted. Opportunities for generating shared mental models based upon object-oriented metaphors present themselves throughout the user-centered design process when you allow yourself to be open to discovering them.
For the sake of getting started with OOUX, in order to combat user-centered design process entropy, let us begin with this sample document fragment which represents a testing protocol provided by a researcher to a developer on an implementation team. The purpose of this document is for a researcher to communicate to a developer which individual screens must be developed in order to allow a user to click through a prototype.
There are a few particular deficiencies with this approach, which fuels systemic user-centered design process entropy:
- The “pages” are vaguely defined and largely conform to the mental model of the researcher who, by this point, has already been discussing and working with various “screens” for several weeks before the implementor.
- The sentence fragments associated with each action could be better expressed in the format more closely aligned to that of a user story.
- There is little visual delineation between “page” and “action”, nor much of a clear relationship between which page an action is associated.
- The mental model being expressed has little relationship to the mental model in use by the developer who must implement this protocol.
- There are no URLs being referenced, which may be confusing to developers who are new to the project and have not been part of the design process to date.
Much of the problem with user-centered design process entropy is rooted in the fact that the implementation phase comes last, well after inadequately constructed mental models are produced by researchers and designers. But various strategies may be employed to help other disciplines understand the value behind the object-oriented metaphor.
Let us imagine that you, the advocate for OOUX, make some adjustments to the prototype protocol document, and you apply some OOUX thinking. You thus render the following:
There is nothing elaborate about this, nor do we need any special software to produce this document. This is a mindset, not a platform. We are intentionally applying a mental model to the protocol and the document, for the purpose of collaboratively generating and sharing a mental model across disciplines. Here is what we did and why:
- The first top left cell references an “object state”. We want to communicate that each page is in fact an object state, and an object is, among other things, a collection of tasks of related objects. We are not working with “screens”, we are working with objects and what we call workflows are in fact collections of related object states.
- Each object state is assigned a clear and concise identifier, such as F1.1 and F1.2. Workflow #2 utilizes object states from workflow #1, which is immediately understood based upon the use of a shared identifier.
- We have borrowed the color coding approach used in OOUX object mapping in order to clearly differentiate between objects and CTAs.
- We have assigned a colloquial name for each object state, since this will be a more effective means to communicate with clients and stakeholders, but the 1-to-1 relationship between colloquial name and object state remains fixed and certain for internal team members.
- Each object state has a definite URL so developers can immediately and unmistakably locate assets that may have already been developed. Additionally, those object states can be demonstrated externally more easily when everyone understands how to access those object states via a web browser.
I think you’ll find, once a team recognizes the need for, and commits to, the creation of an intentionally constructed and shared mental model, the opportunities for streamlining communications, and standardizing how you talk about our UX process, will grow over time.
OOUX thinking is not about prescribing precise methods and tools, but is instead about adopting the mindset and recognizing the value in the metaphors already utilized within your implementation team. Few UX teams fail to recognize the need to more effectively integrate disciplines within the UX process. A good way to start is by bringing your research and implementation teams together to discuss a mental model, and how that may translate into a coherent and easily understandable workflow throughout a project lifecycle, using OOUX.
