I just spent 5 quarters designing a new experience for a legacy enterprise change management solution. Along the way, I learned a lot about the topic, both from documentation and from sparring with the experienced project team. My design proposals often served as vehicles for additional requirements discovery: I’d think I’d have a comprehensive solution for a topic, but team members would point out additional conditions to be addressed. We would then have a long conversation, in which development team members aligned each other’s diverging interpretations of the topic at hand, and educated me on the nuances. To achieve an actual reduction of complexity In some cases, we could “dismantle” requirements that turned out to be mere assumptions. In other cases, there clearly were requirements, and the design had to embrace the complexity. Which is “what we do” in enterprise design.
This makes me, more or less, an “expert” on the topic of change management. I use quotes around “expert”, because, compared to the team members who spent an entire decade working on change management, I am clearly not an expert. As I have been watching my grasp on the topic grow, I have also seen how limited my understanding is.
But my now-sixteen month tenure on the project left an impression. Based on my learning, I’ve been envisioning what a future of change management could look like. In more general terms, the challenge is how to design for process-oriented experiences.
Well, I’ve just done a design, so isn’t the answer in there ?
Naturally, I believe in the solution I worked on with the team. It’s a web application, following inductive principles, using the proven “context within a context” approach. The approach is to use the application structure and flow to guide and reinforce the user’s understanding of the underlying object structure, dependencies and sequences. So far, so good. Feedback is positive all around.
Reliance on the User
There is an implied expectation to make this type of design work: the user is meant to learn the application, to engage and get a handle on the structure, dependencies, and sequences. “Work with me here,” the design asks the user. “Here is an elaborate, custom structure. Explore it, and you will understand,” the design tells the user. As an immediate answer, users are happy to do just that, if the experience offered is engaging in a “fierce fun” game-theory way. But still, the user has to engage with the design. In a general way, this is how software design has been operating. Especially for business software, “learn the tool, it’s a good tool” is a reasonable ask.
Why Make the User do the Work ?
Take a step back. Is there a different way of looking at this?
The user has goals, and software tools help with achieving these goals. The user has a life and a workday outside a given specific software tool, where many goals may be competing for attention.
In this context, a software tool can become a better fit for a user’s life by becoming less demanding: ask for less of the user’s time and attention. The software tool should offer meaningful choices to advance the user’s goals, while allowing the user to carry as little contextual overhead as possible. The tool should be as little a distraction as possible. A “classical” software experience, providing the user with paths through hierarchical screens, even when perfectly designed, does not reach that ideal.
Being less demanding means presenting “just in time” choices when needed, with just the right amount of context, leading to the next choice in a “shallow” flow, until a desirable end state is achieved.
A just-in-time UX approach places new kinds of demands on the user interface delivering the choices, and on the design process behind it. Instead of offering the user a framework of orientation to understand the current situation, the just-in-time user interface must have its own architectural semantic representation of this framework, to distill choices down to the right ones. In other words, the user’s cognitive workload shifts to system workload and state management, insofar as the system will have an internal coding of the choices and state sequences.
In a traditional hierarchical user experience, choices and state sequences are present implicitly. The same hypothetical application, designed hierarchically, or as a low-context step flow, ideally is Turing-equivalent between the two instances (or equivalent in choices made, expressed in an experience-centric measure that is equivalent to computational turing equivalence, but now we are getting geeky.)
Encoding Eliminates Hand-Crafting One-Offs
In a traditional user experience, choices and state sequences are expressed via a hand-crafted hierarchy and flows. This traditional process of “User Experience Carpentry” is fun and proven (the UX field has just been getting to a point where we can finally say that.) But all-manual user experience carpentry is also error prone and labor intensive. Patterns and component libraries act as efficiency band-aids with limited leverage.
Design as Transformation
To get a just-in-time experience, a semantic encoding must play hand in hand with a delivery mechanism for the experience, and offer a way to infuse this delivery with design intent. Sensible design choices in this context are just as important as before, but they change in nature: from hierarchy and flow decisions to transformation decisions. Think of DNA being transcribed by RNA to build proteins, with knobs to turn on the RNA.
A “lighter,” more on-point user experience, will allow users to make better decisions with less cognitive workload and with less time investment. In other words, fewer mistakes will be made, more decisions can be made, and productivity raises. Deep hierarchical applications, even well-designed ones, will suddenly look very old.
New Forms of Conversation
An additional benefit of a just-in-time experience is that it does not have to be delivered in a traditional user experience consisting of screens, windows, dialogs, and widgets. It can, instead be a spoken dialog. Or a written dialog, in emails or chats. Or a hybrid. The point is that when a self-contained encoding of a given set of choices is available, it can be expressed and acted upon in many forms.
Lastly, the form of semantically-enabled UI will be a foundation for working with a different type of user: machines. It can enable a scalable approach to automation, allowing a software to walk through a user experience just like a human user would, without requiring a custom integration between the tool and the “user software.”
Going From Hard to Easy
The innovations envisioned here (sequential UX, automation, UX as conversations) are possible today and implemented today, and have been described before. It all can be done if the budget is right. Achieving those experiences simply requires a whole lot of UX carpentry, which is not that different in effort from making wireframes for an old-fashioned hierarchical web app. The point is though, that the semantically enabled UI, in principle, allows us to avoid costly one-off solutions.
Designers Alone Won’t Do This, But Designers Will Make This Succeed.
Moving user experience forward will not be achieved by designers alone: progress will depend on technical architecture. Besides the actual technical challenges involved, a key success factor will be to keep the resulting tools and conventions within designer’s reach. There is a fine line between tools that actually enable designers, and technologies that take design out of designer’s hands. The latter breed a specialist who can handle the tool, but then the tool fades into irrelevance when technology moves on. When the toolset and the underlying technology are decoupled, then either can evolve freely and absorb innovation, for better execution capabilities and for best-fit authoring tools for specific users.
Anyways, there are some things to do.