A common pitfall I’ve observed over the years with design practice is excessive focus on “main” flows. Scenario development, journey mapping, concepting, and prototyping by their nature revolve around a main expected path. However, the overall experience must be informed by the potential alternative paths, not just error paths, but different paths to a successful outcome that the system must support as part of the experience.
Understanding alternative paths is critical to effective screen-level design. Absent accounting for alternative paths, your design is unlikely to hold up once it goes into development. …
There’s a new tool in town. It has been the subject of a lot of hype in the productivity space, some of it warranted, some of it not. It’s a power tool and, admittedly, not immediately intuitive. There is some cult-like devotion to it, and, as one might expect, a related backlash.
In this article, I’m going to step through a process of using this new tool — Roam Research — to capture and analyze qualitative data from user research.
It was the early stages of a new design project, and I was working on a task flow diagram when a colleague asked me about it. “You’re doing that now? I normally wait until the end of the project.”
I understood what he was saying: he would do the design and then include additional artifacts such as a flow diagram to document the design intent. It struck me, however, at that moment, how integral documenting design is for me to the actual creative part of doing design.
Indeed, in the early stages of design, it’s important to sketch and do…
As UX designers, we are fundamentally engaged in helping users perform tasks. As such, we spent much time designing from the task perspective — understanding how tasks are currently performed and crafting ways tasks can be performed more easily and enjoyably in the future. In this article, I look at artifacts and methods used to work from the task perspective throughout the lifecycle of a design effort.
Keep in mind, however, that the task perspective is one perspective — designing necessarily means also working from the structural perspective. …
In my last article (a two-part series), I outlined special considerations around journey mapping for the enterprise. In this article, I expand on why, for the enterprise, characterizing users in terms of roles is more useful than traditional personas. Further, I’ll explain how to characterize roles so that they have a most meaningful impact on design.
A role describes a group of individuals who perform the same function. Roles often, though not always, conform to job titles in an organization. An individual’s knowledge, skills, and behavior are bounded (at least at a high level) by requirements of a role. I…
In Part 1 of this series, we looked at creating a current-state journey map for an enterprise experience. In this part, we’ll look at creating a future-state map.
This article assumes that you’ve first created a current-state map, though that artifact isn’t strictly necessary for future-state mapping. You do want to make sure there is, as a baseline, a clear understanding of the current experience: how work is getting done, what is working well, and what sort of difficulties exist. …
Journey mapping provides a concise, big-picture view of an experience that can align stakeholders around a vision for improving the experience. A journey has a start-to-finish flow — traditionally a consumer making a purchase decision, as shown in the example below.
Journey maps can also depict enterprise experiences, though consumer and enterprise journeys fundamentally differ. One main difference is one of perspective. Consumer journeys usually are written from a single perspective (a customer persona) while an enterprise journey typically needs to capture how work is accomplished across various roles or departments.
As someone entering their 20th year of design consulting, I’ve had the chance to work across a wide span of projects: from simple consumer apps to large, complex enterprise systems. My heart, however, resides with those sometimes-pesky, always-interesting enterprise applications. I love the design challenges and having the opportunity to transform peoples’ work lives.
Along the way, I’ve developed six cardinal rules when designing for the enterprise. These rules are by no means a set of comprehensive design practices, but they are key elements that I’ve found lead to more successful design outcomes.
As a user experience designer, it can feel as though I am waging an on-going, never-ending battle against complexity, especially when working on enterprise systems.
A popular route to simplify an experience is to implement a design system. A number of full-fledged design systems are accessible on the web, and it doesn’t take much of a discerning eye to see the influence these systems have had on application design (an influence I’ll say more about later).
Design systems are essential, but what I hope to show in this article is that a design system alone — particularly if it’s primarily…
Principal UX Designer & Partner at Blink UX • iPad enthusiast • GTD practitioner • Crafting better enterprise experiences since 1988