View this email in your browser


Overcoming Objections

Conceptual modeling despite resistance. Plus Ben Mosior on Wardley maps and other things worth your attention.
Jorge ArangoJorge Arango
March 21, 2021

Welcome to INFORMA(C)TION, a biweekly newsletter about systems thinking, information architecture, strategic design, and other topics relevant to humans who create digital things.

If you enjoy this email, please consider sharing it with others. And if you're not subscribed yet, you can sign up here. Thanks for reading!

Water flowing in a small creek
Water flowing over and around rocks in one of our beautiful East Bay parks.

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.

A tweet by Kim Goodwin that says: "Every client I’ve seen with significant architectural issues either doesn’t do conceptual models or fails to involve the design team in doing them. I often find designers without either code or IA backgrounds who’ve never really used them."
A reminder: pointers to Amazon in this newsletter are affiliate links. I get a small commision if you buy from Amazon after clicking on these links.

Also worth your attention

  • UX or UI? Kyle Turman’s “Pillars of Digital Product Design.” My new go-to explainer for people starting out in the field.
  • The Elements of Digital Ethics. Per Axbom's “chart to help guide moral considerations in the tech space.”
  • IA and accessibility. Sarah Barrett: “Accessibility is usually seen as a problem for people who code and people who pick colors, not information architects. I have bad news: Your IA is almost certainly a huge accessibility problem.”
  • IA and chess. Jessi Shakarian on the relationship between information architecture and chess. (Jessi's post prompted me to revisit the origins of this analogy.)
  • The Paradox of Genius. Kevin Kelly on long-term thinking for startups.
  • Relationships > Content? Eli Pariser on filter bubbles, 10 years after he coined the term: “The place where I’ve probably changed my mind the most is that the filter bubble was a content-centric way of thinking about what people need to know in order to understand the world. And I think the more I thought about it, the more I’ve wondered if really it’s about relationships, and the content is kind of a layer that sits on top of the structure of your relationships.” (H/t Duane Degler)
  • Subscribe Follow. Apple is changing a key label in its (industry-leading) Podcasts app. A good example of a counter-intuitive research-driven IA insight.
  • ‘Quiet’ note-taking. A year into remote work, I’ve adapted my note-taking approach to better manage focus during meetings.
  • The Fidelity Canvas, a framework for “making complexity approachable by leveraging context.” (H/t Sean Jalleh)
  • Oh my Git! A game designed to teach Git, the leading version control system. An example of how to communicate a complex conceptual domain in an accessible way.
The Informed Life episode 57: Ben Mosior

Episode 57 of The Informed Life podcast features a conversation with consultant Ben Mosior. Ben teaches clients how to visualize strategic intent using Wardley maps, which are the focus of this episode.

Wardley maps are a type of systems diagram that is particularly effective at capturing context and intent. The mapmaking process brings clarity and alignment to teams and organizations, allowing them to act with greater intent and focus.

I'm grateful to Ben for sharing his knowledge with us; I hope our conversation proves as valuable to you as it did to me.

The Informed Life episode 57: Ben Mosior on Wardley Maps

Parting thought

All models are wrong, but some are useful.

— George Box

Thanks for reading!

-- Jorge

P.S.: If you like this newsletter, please forward it to a friend. (If you're not subscribed yet, you can sign up here.)

Share Share
Tweet Tweet
Forward Forward
Copyright © 2021 Boot Studio LLC, All rights reserved.

Jorge Arango
Boot Studio LLC
P.O. Box 29002
Oakland, CA 94604

Disclosure: This newsletter may include Amazon affiliate links.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp