Hidden Movements — Introducing The Constellation Model
This article is a variation of a discussion that can be found on my portfolio page. For more information on where and how the Constellation Model was used in pursuit of a design project, please read about it here.
Gone in 60 Seconds
In a rush?
Here you go: The Constellation Model is a method designed to help UX designers and researchers more accurately think about and represent their users. Whereas most methods — such as personas — fall into the trap of visually imagining and subsequently representing users as static forms, the Constellation Model treats users as dynamic agents of change, and in so doing helps keep this capacity for change at the forefront of a designer’s thinking.
Okay. We made it. Now — do you want to know more?
Road-Ready Tools for the Scrappy Designer
Personas, for better or worse, are under siege.
There are a variety of reasons for this, from personal vendettas to the well-documented fallibility of the method. This sort of pushback against something in design (whether a method or terminology) is nothing new. Recently, for example, we’ve seen a movement away from the term “design thinking,” for a variety of reasons.
Yet the persona has staying power — and for good reason. Generating a persona is a tested, road-ready method, and it’s efficacy often outweighs its shortcomings. Perhaps most importantly, it’s relatively quick. For designers, time is a luxury. Often, we don’t have a lot of it.
This is all fine. Good, even. But what about when a designer has a little more time to invest? How ought they allocate this most precious of resources?
Ultimately, this article is less concerned with tearing down personas and more concerned with proposing another route to take in the event a designer has a little more time to spend. Some might even argue that the so-called Constellation Model is simply an evolution of (or a companion to) the traditional persona, and this is an argument easily made. I certainly don’t have any qualms with it.
But what is the Constellation Model? How did it come about? What, in the words of James Brown, is it good for? (Hopefully more than absolutely nothing.) In a sentence: the Constellation Model of visualizing the User is a web of dynamic nodes that changes over time wherein different nodes indicate different attributes of a target user group as identified in research.
So far, so good.
But where did it come from? Why does it matter?
To answer this, we have to dig a little deeper.
Origins of the Constellation Model
Let’s start somewhere concrete by plotting this out on a timeline.
The Constellation Model first came about during the first phase of the development process for a project called Eclipse. This project was developed by me and my teammates during our first semester of Indiana University’s HCI/d MS program. This would put the first iterations of the Constellation Model somewhere in the fall of 2018.
To understand why we made the Constellation Model, we need to look a little closer at the project itself and why we felt we needed it. In its final form, Eclipse is a voice tracking software that measures the amount people speak in corporate meetings while still preserving their anonymity.
Ideally, Eclipse helps team leads see who might be hogging conversations and/or identify people who are speaking less than they want to. Likewise, Eclipse empowers team members by allowing them to visualize one factor in how they are appraised by their team leads and other managers. This idea of visibility was how we satisfied part of our prompt, to design for respect, which is the bit that matters for this discussion. It’s this part of the prompt that the Constellation Model helped us navigate, as I’ll examine a little later.
As expected, our early conversations in the shadow of this word — respect — were protracted, sensitive, and marrow-deep. Vitally, our first agreement as a team was to embrace the premise that — for the purposes of our design — respect is not synonymous with acceptance. This design argument proved more controversial than it first appeared. Let’s unpack it a bit more to better understand why — and perhaps even more importantly, to illustrate why thinking about something like respect should matter to even the most hurried of designers.
Design as Social Issue
Design is a deeply social issue. And for good reason! Good design isn’t done in a vacuum. Good design is done with and for other people. The question of respect, therefore, is not some distant, purely theoretical discussion. Rather, the question of respect is deeply relevant to the central discourse.
But what does respect mean? How does the busy designer map the implications of said meaning to the user-as-user-of-product way of thinking?
This was a tricky question to contend with. And it didn’t help that a word like respect is so overused that it ends up being vacuous unless we spend the time (we don’t have) to properly interrogate it.
Yet even a moment’s consideration reveals the necessity of these kinds of discussions for the designer. Consider: Some believe that in order to respect someone, you must accept them. Others believe that respect is a standard social currency, given by default until someone gives you a reason not to.
Okay, fine. These are both popular philosophies, with a multitude of intelligent, well-intentioned followers. But what happens if we consider these viewpoints in conjunction with one another, especially from the perspective of experience designers? How does this affect something tangible like, say, our metrics for success?
If we apply — even subconsciously — these two respect arguments to a design’s metrics for success, we hit an insurmountable problem: the standards required for our design to be considered “respectful” quickly balloon out of control. Any design is stopped cold in its tracks long before it’s even had the chance to be iterated past the whiteboard.
What are we left with then, as designers, but making the conscious decision to proceed with our design knowing that it disrespectful?
Here we illustrate a classic trap— that of conflating respect and acceptance, a common mistake which often cashes out at the expense of both. How many people do you know who don’t respect — or who don’t treat respectfully — individuals of a different religion or sexual orientation because they do not accept that lifestyle or faith? If contingent on acceptance, respect is too easily abandoned. This is the danger of coupling these two words.
Put bluntly, being accepted by everyone for every aspect of our personhood is not — and cannot realistically be — a universal social right or expectation. Being treated respectfully, however, can be — and, we as a team argued, should be. This is not to say that this an easy path, given the slippery nature of what constitutes being respectful. Yet despite this challenge, it was in this latter construct of thinking that we made our eventual design.
Most importantly, however, was the visualization we used to express this idea of a person as an aggregation of aspects and parts to ourselves and later to our testers. You guessed it: a constellation.
Let’s dive in.
Visualizing the User as a Constellation
As we learned during our conversations about respect, it helped to visualize the terms at play. To do this, we sketched out our ideas in a recurring form. Later, we would refer to these drawings as the user as a constellation model of understanding.
The user as constellation model (or the constellation model, for short) is straightforward, suggesting that a person’s identity is built on several different attributes and preferences, including (but not limited to): religion, eye color, favorite food, political inclinations, and so forth. Each of these data points is simply a part of the greater whole.
Following the metaphor through to its conclusion, we refer to these nodes as stars in a person’s constellation. Orion, for instance, is not any one star, but several. So too is Ries.
Now we return to the question of respect and acceptance.
As mentioned before, respect is commonly confused with being respectful. This, too, is an error. Simply put, you don’t have to respect someone in order to be respectful. Being respectful is part of the social contract. Respect, on the other hand, is both intangible and personal.
While acceptance and respect are closely related, they are not inextricably linked. There can be elements of a person (or nodes) that one does not accept while still accepting the whole. If anything, treating people respectfully becomes more important when dealing with someone whose ideologies, personality or lifestyle you do not accept.
This is part of what constitutes the fabric of society. Without this compromise, we fall into our most vicious selves, prone to war, violence, prejudice, and bigotry. It’s this view — the view of seeing one another as a whole, rather than an amalgam of nodes or parts — that a designer would do well to embrace.
Back to Bread, Butter, and Business
Let’s shelve the discussion of respect for a moment. Talking through it is all fine and good, but what does the interrogation of respect have to do with the “bread and butter” real-world, every day UX design? In other words — why does any of this matter? I’ve been patient, now show me the money!
As it happens, for our design frame we targeted the workplace rather than an academic setting. This was because of our collective assumption that companies and other corporate environments (e.g. government) have a long way to go in the game of respect. (Our research would reveal this assumption to be painfully accurate.) Specifically, we targeted the place where people interact the most (or at least, the most consistently) — the meeting room.
Yet even at this early stage, we began to struggle with another question: who was our design going to be for? This would prove the first significant roadblock in our design journey. Any strong design has a clear user at its heart. We believed — and believe — a clearly articulated user keeps an honest designer honest.
Targeting meeting rooms in a corporate environment, however, proved problematic from this user-centered design perspective, because in any meeting room there are two roles that potential users fall into: that of the supervisor, and the team member.
On the surface, therefore, it appeared that our design would either empower the worker — or it would enable the supervisor. The needs of these two user groups are often at odds with one another. Helping one risks hurting the other. While it might be seemingly noble, for example, to defend the underdog in any power structure, from what angle do we as designers realistically stand a chance to affect meaningful change? The answer seemed to be: from as high up in the chain of power as we can aim.
Yet is this not a betrayal?
Don’t we have a duty to design for those who need our help the most?
Visualizing the User as a Person
Early interviews revealed another problem — this time, with the Constellation Model itself. While our participants agreed that the Model (and its subsequent mode of thinking) were pointing in the right direction, they also suggested that on the whole, the Constellation Model was flawed.
While people liked the idea of being represented as a “constellation” (one individual called this a “romantic way of thinking about myself”) — a new issue arose when a separate participant (who we will call Samantha) pointed out that the Constellation Model overlooked the fact that not all stars (or nodes) are given equal weight in a person’s life.
Someone’s religious preference, Samantha argued — or gender identity — would be a bigger star in their constellation than, say, their identity as a student, or as a fan of the Green Bay Packers.
If someone chose not to accept this larger-than-average node or star, the impact on how they perceived Samantha would be more drastic than if they took issue with a smaller node, such as her preference in food, her favorite sports team, or her favorite season of Game of Thrones.
Additionally, Samantha did not perceive her “stars” as being static; rather, she argued, her stars grew and shrank depending on her circumstance. Our insight was simple and profound: People are dynamic. So too must be their Constellations.
We Are Not Things
Here’s the thing: I don’t have an issue with personas.
In fact, I think personas are tremendously valuable for designers, provided they are the consequence of rigorous research. The danger of personas is not unique to them, specifically. Rather, the danger here is of the same kind of danger we flirt with anytime we speak of “target users,” “ideal users,” “end users,” “clients,” “customers,” etc.
All of these terms speak of the user as something that can be visualized in a static form rather than someone to whom movement, dynamism, and change are inherent to their identity.
Put another way, when we think of the user as a thing we are tempted to represent them on paper as a persona, or draw them out in nodes in a constellation. It’s only when we remember that they are a person that we begin to see how flawed this approach is, and how easily this sort of thinking can lead us astray if we’re not careful.
This is exactly what happened with Eclipse.
As discussed earlier, the wants and needs of the supervisor and team member roles are often at odds with one another. As such, we had a hard time finding a design that satisfied our target user without disrespecting whatever group we didn’t target.
This problem seemed intractable, but in fact was an illusion — and it was an illusion that came about because we were thinking about the people in the wrong way.
Porque No Los Dos? (Why not both?)
In the end, it all comes down to movement and motion — an idea already at play in other widely accepted methods. (One such method that comes to mind is the Journey Map, which accounts for fluctuations of emotional state as a user travels along the flow of time.)
For us, the breakthrough came during usability testing.
It was our second usability test for Eclipse, and the participant was a Program Director at IBM. When asked to describe her job, she responded by saying “I’m a manager who manages managers.” This simple sentence — and the subsequent conversation — proved to be the key.
Our early ideas surrounding our “ideal user” did not embrace the complexity of real people because these ideas came about from using static design models. Instead, we learned that real users who would leverage the Eclipse application would not simply be either a team member or a supervisor.
This is because while such roles do exist in a corporate meeting room, real-life people do not sit exclusively in one or the other. Rather, most real users fill both roles, often simultaneously. In one room, James might be a team member — in another, he might be the supervisor.
Sometimes, it’s even more complicated than that — as one user tester (a supervisor) said, occasionally their team would meet with someone even higher ranking in the room, simply to observe. How is a hierarchy such as that handled and acknowledged in a system?
These are true design problems to contend with — and we did. We would never have discovered these challenges, however, if we’d stayed stuck on the wrong way of thinking about our users in the first place.
There are several possibilities for further research here, in terms of seeking agreeable matches. We might find ways, for instance, to link Constellation Models with Journey Maps so that star fluctuations might be mapped to crests and valleys of an experience path.
I don’t know how far the Constellation Model can go. I’d love for designers to test it in their design processes and to let me know what they learn from it. I’d love to get it out there, and to hear when it worked — and when it didn’t.
One thing I do know is this: People change. Sometimes, people can change from moment to moment. This is part of who we are.
Conclusion: Hidden Movements
There’s a motion to people, even when they’re sitting still.
By understanding the nature of this hidden movement, we begin to unravel several mysteries: why some people don’t photograph well, despite being beautiful in everyday life; why Picasso’s works, such as Nude, Green Leaves and Bust feel both true and erotic despite their esotericism; why we are first arrested by, and later obsess and puzzle over the old stone sculptures, such as Michaelangelo’s David, or Bernini’s Rape of Prosperina.
These hidden movements are why stock photos and CGI rendered faces all too often fall into the depths of the so-called uncanny valley. Despite their myriad of talents, contemporary artists have not yet attained the skill of the masters, who long ago learned to capture and express our most vague, secret motions in paint and stone.
As UX Researchers and Designers, we would do well to remember this. Our users are not things. They are people. Certainly, there’s value in building out a standard archetype to work towards. And certainly, it’s more feasible to guide our designs with a muted reflection of the world rather than to try and incorporate what Erik Stoltermann would call “the full complexity of reality.”
Yet we are wayfinders on virgin seas. We must act as such. We rely on our Northstars, rather than all the stars in the sky, and this is good. But we must also remember that at the end of the day — stars are fixed. Oceans are not. Water breathes. It moves. As designers, it is to the metaphorical sea — not the sky — that we must look and adapt.
Share your thoughts below! What do you think of the Constellation Model of User? Is this a method you’d try out in your own design practice? Why or why not? What other methods out there share resemblances to the theory at play here? Let me know!
