Photo cred: BBC, Sherlock

Mapping Intentionality

Hypothesis: The most important thing in designing interfaces is understanding and directly catering to people’s intentions.

Tshepo Mohlala
Design by Tshepo
Published in
4 min readOct 9, 2014

--

There’ve been several attempts at formalizing the field of user interaction design. And whether or not you believe it can be done — at least enough to be on intellectual par with, say, economics — it’s important enough to try. Just look at all humanity’s accomplished technologically through the formalized principles of mathematics.

To be clear, I’m not advocating formalization simply because it works really well in math. The main motivator is actually the susceptibility I keep seeing of interaction design to certain rigorous frameworks. In particular, to complexity theory. The main benefit of this susceptibility is being able to design interfaces much faster and with more reliably positive results.

Now, interaction design borrowing from complexity theory isn’t an entirely new thought. User flows are actually transition diagrams roughly adapted to the qualitative necessities of design. But for several, incidentally good reasons, the consistency/rigor in this methodology as applied to design is virtually nonexistent. Perhaps the best reason for this is that it allows designers to come from all disciplines — from self-taught to art school to mathematics. It’s a phenomenon that lends invaluable perspective into different users’ predispositions.

Let’s talk about people. Design is centered on improving the usability of things for people. Indeed, design is meant to fit our sensibilities — perhaps even to realign them when they prove obsolete.

Now, for a second, forget people. Blasphemous, I know. But what I’m suggesting is that, before we embark on modeling interactions based on our understanding of people, we should first understand how we’re influencing our own ultimate goals. I’m suggesting that we first put down on paper the most important things we think people want to do (i.e. the things our product is meant to help people do) — indeed, taking it under assumption. Then, between these taken-for-granted actions, we fill in the most likely sequence of motivations/intentions that would get the user to those and other, revealed actions. I say revealed because another important thing about this methodology is that it uncovers solutions to serve what people are trying to do.

To preserve the aforementioned accessibility of design, I suggest we formalize only the really important things first, then later attempt grander and deeper formalizations in the vein of Gauss et. al. as seen in math. Here’s a simplified example of mapping intentions:

Each box is called a state. The double-border box marks a primary exit state. We can have multiple of these. The box with a disembodied arrow leading into it (i.e. the feed box) marks the sole entry state. We can deal with multiple virtual entry states with a workaround, which I’ll document later.

Why this is better than standard user flow and wireframe techniques for creating and improving interfaces:

1. It captures, defines, and helps discover:

user flow through the app/site

user’s intentions, not incidental actions, from state-to-state

structural scale of the app/site.

2. It formalizes questions and helps diagnose problems. For example:

what user need/intention is under-served?

where in the user flow can a new feature fit?

why are users leaving the app/site at state G?

3. It simplifies the design process.

The standard technical approach to creating an app/site (or solving problems for them) is to create diagrams of screens (i.e. wireframes). But the full-blown wireframe of an app/site tends to hold too much incidental information for this task and in effect hides problems through cumulative complexity. Indeed, I think of full-blown wireframes as a blueprint — meant for reference when building. We should create interfaces and solve problems in a medium meant/designed for that, then map out visual components in a medium meant for that. This is all for the sake of reducing the time between inspiration and execution with positive results.

4. It seduces the designer into testing and applying specific solutions.

By mapping out intentions, we inherently ask ourselves how to serve those intentions.

5. It’s easy to understand for everyone from designers and engineers to marketers and execs.

6. Easy to codify/store.

All of this could be stored quite easily in an (n+1) x (n+1) matrix indexed by n states (plus a null state), populated by intention entries, and traversed by a lexicographic ordering rule. For those unfamiliar with these terms, it just means a grid that codifies how different intentions and states are linked.

I’ve been developing this process under wraps for a while and have only applied it to personal projects. I’m finally getting to a point where it’s a simple and quick process to communicate and replicate. Hang tight for more.

--

--