In Dec 2014, Mark Rosewater (veteran head designer of the world’s most complex game) wrote Lenticular Design, borrowing a term to coin a new one in game design. I first read it many years ago, and have spent considerable time pondering how it applies to software product development. If you have any sense of how Magic: The Gathering is played, I strongly recommend reading the original.
Below, I adapt his essay by editing it down to its key points and lightly translating terminology to make the crossover to software products apparent. Extended quotes are preceded by ‘>’ to indicate the paragraph is primarily Mark’s words with my term changes in [square brackets]. I hope this makes the crossover apparent and easy to understand without misconstruing the ideas Mark communicates in the original.
Introduction to Lenticular Design
> Retention of your current audience is crucial, but people will always leave, often for reasons that have nothing to do with the product itself, and in order to maintain the [membership], you have to add new blood.
> I think when most people look at complexity, they think of it as a scale. They deduce how complicated it is in general and then they place it at the appropriate spot. What I realized was that complexity, that is how complex a particular [feature] is for a [user] to comprehend, varied from person to person.
This may seem obvious, because advanced users find it less complex, but there’s a surprising part:
> Some [features] were more complex to advanced [users] and less complex to beginners. What? How is that possible? The key is that some complexity is hidden, because it requires certain knowledge to even be aware of it. It turns out that some [features] appear on their surface to be very simple, but once you understand more about how to use them, they become more complex.
Types of Complexity
Comprehension Complexity — can you comprehend the function of the [feature] once you’ve read it[s description]?
- vocabulary that’s not understood
- text that is hard to process
- [has too many interactions] to process
- unclear benefit — why do this?
[State] Complexity — how the [features] interact with one another once they are [activated]
- [features] that affect other [features] — makes the [configuration] significantly harder
- [features] that are affected by other [features] — hard to track because it requires you to always be aware of other [features]
Strategic Complexity — how the [features] are maximized [for impact]
- they offer the [user] so many options
- a [feature] might be strategically complex in one [use case] and less so in another
Basic Rules of Lenticular Design
#1 — Some Complexities are Invisible to Inexperienced [Users]
> Novice [users] notice comprehension complexity immediately, because their main goal is making sure they understand what their [features] do. [State] complexity is invisible at first but it doesn’t take too long for them to start looking at [feature] interactions. The real ghost of complexities for less-experienced [users] is strategic complexity. Because it requires a lot of knowledge to understand context, strategic complexity can take [users] quite a while to start seeing. Lenticular design uses this to great advantage.
#2 — [Features] Have to Have a Surface Value
> When newer [users] [see a feature], they need to feel they understand what they do. Once they do, they move their attention to the next [feature]. This means that, when designing a lenticular [feature], you have to make sure it has a surface value—it has to appear to do something. The corollary to this rule is that the [feature] cannot have any [option] that does something the player cannot understand.
#3 — Experience Is Connected to How Far Ahead a [User] Thinks
> But it’s not for a while before they start to think about more advanced concepts such as, “I can [do this action] right now, but is there a reason I might want to wait to [do] it later?” It is in this space that lenticular design tends to thrive.
#4 — Novices Tend Not to Think of Causality
> This means that a helpful way to create lenticular [features] is to add abilities that appear on the surface to be fluff.
#5 — [Users] Will Try to Use the [Features] to Match Their Perceived Function
> As such, it is important to remember that a good lenticular [feature] has to encourage the proper behavior for each type of [user]. For beginners, it wants to encourage [them] to use it. […] For experienced [users], in contrast, lenticular [features] want to have strategic depth, most often meaning the [feature] will have different uses based on the state of the [community].
Don’t let it create a worse experience for the novice.
#6 — Let the [Users] [Engage With Product How] They Want to [Engage]
> The key to good [feature] design is creating a [product] that maximizes the [users] doing what they want to do. Remember that it’s the job of the designer to make the [product] head toward a state that will cause it to [have the desired impact]. For beginners, that means you want them to [engage as much] as possible and have things happen that they understand and enjoy.
> For advanced players, you are trying to give them the tools to [succeed], but you do not need to be nearly as blunt. In fact, the more experienced players want to feel as if the designer is giving them the resources to create their own experience. They don’t want to feel led down a path, but rather, given a giant map to explore.
Summary
> Often, when I talk about making the [product] more accessible to beginning [users], the focus is on simplification. Today’s article is trying to demonstrate that it’s much more complicated than that. Sometimes, it’s not about removing the complexity, but hiding it. Sometimes, it’s about finding a way to create a simple [feature] to allow options for those looking to find them. Sometimes, it’s viewing each [feature] through various lenses to see how different [users] will perceive it.
While I think it’s worth noting there are inevitably gaps in overlaying Mark’s words on game design directly onto software products, I think it’s lightyears ahead of how we tend to talk about the complexity of user experience and we could gain a great deal by using it as a new starting point.