|
Recently, I asked on Twitter,
What’s the best objection you’ve heard to making conceptual models as part of the design process?
A lively discussion ensued. Some respondents were unclear on what I meant by “conceptual models,” which speaks to the lack of mainstream awareness of this crucial design artifact. (Here’s my latest stab at clarifying.) Others, clear on what conceptual models are, pointed out that the process matters more than ‘deliverables.’ Great point.
But I’m especially interested in the objections. Here are some that represent what I see as the main gist.
Chris Avore pointed out that conceptual models are seen as “too hand-wavey or theater-like,” and that they “lead to a few head nods but the world/plan/goal doesn’t change at the end.” To put it bluntly, as Hà Phan did, some people see conceptual models as “bullshit.” (My take: true insofar as they know about modeling at all; I suspect most people don’t.)
To put it in more business-friendly terms, many people perceive conceptual modeling as a waste of time and resources. Looking at a conceptual model, stakeholders may wonder (as Hà put it), “What is this? What am I looking at? Why does it matter?” They don’t see value in burning design cycles to create potentially ineffectual artifacts — that is, (and here I’m reading into it,) abstractions that don’t manifest as things that look like screens.
This is a common objection borne out of a misunderstanding. I’ve been in projects where stakeholders wanted to jump straight into screen-level design, forgoing not just modeling but research altogether. I find the phenomenon especially prevalent among folks with a marketing background, perhaps because they’re used to thinking about design as visual design. They don't see design as a strategic partner in defining a solution but as a production function.
But digital products, services, platforms, etc., are much more complex than a billboard or poster. You can’t design a system to diagnose brain injuries or allow people to find stuff in a large website using the same methods with which you design a logo. While the latter may call for some research, the former require a more in-depth understanding of systems, subject domains, and user mental models.
Conceptual models bridge the gap between the system’s complexity and its users’ (inevitable) lack of understanding. As Johnson and Henderson call out in the subtitle of their book on the subject, conceptual models are “core to good design.” We must research and model the problem domain if we are to do a good job.
Here are three suggestions on how to do so in organizations that are unfamiliar with modeling.
Leverage research.
Modeling is a natural way of translating research findings into actionable insights. It may be that stakeholders don’t value modeling, but value research. Use that framing to your advantage.
You’re not explicitly setting out to ‘sell’ anyone on the merits of modeling. Don’t push models as a deliverable, but point to model-driven insights when asked to justify screen-level design decisions. Over time, stakeholders will come to see the value of the approach.
(If your organization doesn’t value research, you have bigger issues to deal with; consider what to do about that instead.)
Avoid cargo-cult modeling.
If you’re lucky enough to work in an organization that's open to modeling, do it properly. Nothing undermines confidence in a method like following the motions without understanding what it’s for or why it’s being used.
I’ve seen other design artifacts, such as journey maps and personas, misused to justify decisions that have little to do with research-driven insights. The potential for misuse is especially high with conceptual models because they’re so abstract and flexible. Furthermore, there are fewer public examples available of good models.
Model the domain, but do it well. Don’t start until you grasp the subject, system constraints (and capabilities), and user mental models. The conceptual model will help refine your understanding of all three, but you must start from baseline research and a hypothesis of the system’s objectives.
Model anyway.
Ideally, conceptual modeling happens with stakeholder support. But in some cases, gaining that support won’t be possible. What do you do then? You model anyway. As Austin Govella put it,
I just do [the models]. 1. Client doesn’t need to know or sign off. Unless they do, in which case 2. We just do them. Unless client doesn’t want to do them, in which case GOTO 1
The rogue approach isn’t about being obstinate but about being professional. As I’ve said repeatedly, models come before screens.
That said, don’t go over budget or blow deadlines. Stakeholders want to see proof of progress, by which they usually mean screens they can react to. If you’re deciding between modeling and creating highly polished wireframes, you’re doing it wrong. Lower your criteria for screen level artifacts so you can spend some time modeling. Measure twice, cut once.
As with everything we do, the goal isn’t to create beautiful artifacts but to design a system that serves user needs while furthering organizational objectives. Design artifacts and processes should be in service to creating value for its users, the organization, society, and the planet.
It’s easy for designers to fall in love with (and therefore promote) our cool, elaborate, beautiful creations. Our colleagues in other parts of the organization may see this as frivolous, wasteful, and self-indulgent — and they may be right. Tone it down. Conceptual models are a means to an end, not an end in themselves. Do the work professionally and humbly — but make sure it gets done.
|
