I had recently published the article UX Design is dead – long live UX Design and described in it why I think a new understanding of the role of UX Designer* is urgently needed. My call then was:
Let’s modernize the role ‘UX Designer*in’ together to make the digitalized world of tomorrow a little bit better with better products and services.
One reason for the call was that even after many years in the industry, the gap between UX designers and software engineers still seemed too big to me. Fortunately I got a lot of input from other professional UX & CX or digital design professionals, software engineers or – in general – product creators. Thank you for that, because it gave me the opportunity to further sharpen my thoughts on the role of ‘UX designer’.
There we have the villain: design did it!
Based on the feedback, I now think that the root of the problem is not the role of UX designer, but the term design itself.
The term can take on two fundamentally different meanings due to various origins and interpretations:
Design is creation and shaping.
or else:
Design is the making possible of a technical implementation.
One can discuss a lot about which definition is the “more correct” one. But I think that this discussion is idle. If you take a human-centered approach, then the only thing that matters is what those people who have a legitimate interest in design – the stakeholders – understand by the term design. Because without these stakeholders, there would no longer be any design, but only art.
Design is what appeals?
If I take into account my experience in hundreds of UX projects as well as numerous applications and successes of my company at various design awards, I come to the conclusion that design is not interpreted by most stakeholders as making a technical implementation possible, but in the following way:
Design is what I personally like.
Unfortunately, this is not a viable definition for everyday professional work, because too many questions remain unanswered:
Is design more about what pleases financiers and decision-makers or what pleases users? If no one really likes the look of a wireframe, is it not design at all? But why do UX designers create wireframes? Is a design system, a system that consists exclusively of elements that already have to please? But what if a design system contains pleasing elements, but can be used incorrectly due to a lack of DesignOps infrastructure, and the resulting product is therefore not pleasing to the user? Is it then not a design system at all? Or simply a bad design system?
Design is no deliverable!
Unfortunately, one can only answer these questions contradictorily. In my opinion, the reason lies in the following important statement:
Design is a process and not a deliverable.
To put it more precisely, design is a process of creation, i.e., a process in which one primarily creates rather than analyzes. Or – to use an image at this point:
Design is a “sleeves up” and not a “glasses on” process.
Of course, it is difficult to make a clear distinction here as well. Shouldn’t we, as good designers, first roll up our sleeves, then create something, then put on our glasses to see if we like it, and then continue to fine-tune our work accordingly? Or better yet, should we put on the glasses before our very first design activity and then again and again? Similar to sculptors who first go through the world with their eyes open to gather inspiration, then begin their work and each time after a few blows of the hammer examine their work with narrowed eyes and extended thumbs (or better yet, have them examined by the client)?
Sad but true: no way around the deliverable
The described interplay of creating and analyzing is of course the key to a good design process. But this interplay is only not a problem as long as the designer can manage the design process alone and with himself.
If the design process is spread over many shoulders, as is the norm in modern product teams, then things look very different. Then the team is forced to think in terms of deliverables and intermediate deliveries. Because only by delivering an intermediate state to the next in the chain of creation does the design process keep going. And again we are stuck in the dilemma that design could very quickly be seen as a deliverable and not as a process.
So my concern is that design is understood as a cross-team creation process, while the deliverables that fuel that creation process are understood as something else yet to be named. “Something else yet to be named” remains unsatisfyingly vague at this point, of course.
But sometimes what something is is explained by explaining what it is not.
Do UX Designer create wireframes?
If we look at modern UX design processes, we cannot avoid dealing with the obligatory wireframe, because it is currently omnipresent in the collaboration of digital product teams and is commonly understood by stakeholders as a kind of design manifestation.
However, if design is not a deliverable at all, but a process, then the following important key message emerges:
A wireframe is not a design but a deliverable.
Which logically leads us to the following statement:
The main task of a UX designer is not to create wireframes.
Granted – this causal chain seems like a shell game trick. It sounds like I’m trying to devalue the role of the UX designer for the hell of it, and in the process, devalue wireframes as anti-patterns right along with it. But that’s not what I’m about.
I want to focus on how UX designers’ excessive focus on supposed design deliverables like wireframes can cause an entire creative process to flounder.
Better deliverables are also an option
Jeff Gothelf writes pithily in his great Lean UX book:
Get out of the deliverables business!
As much as I subscribe to this quote to swing the pendulum: I also feel caught again and again that it just doesn’t work without deliverables. The creative process doesn’t even flounder without deliverables and artifacts – it goes completely flat.
So it’s better to deliver bad deliverables than none at all? That would be one option.
Another option is to take another thorough inventory of the deliverables box and ask: In terms of a good design process, what belongs in our deliverables box and what needs to go out?
To temper expectations, no matter how well we have cleaned up our deliverables box, we will be disappointed if we cannot communicate well as a team:
Communication and documentation is the mortar that makes our deliverables building blocks layered on top of each other hold up at all.
From that perspective, wireframes are definitely deliverables to consider – they’re just unwieldy and require lots of additional communication or documentation to have a positive impact on the UX design process.
To stay in the image of the constructive creation process, with wireframes we’re dealing with huge, unwieldy deliverables bricks with no mortar in between.
And this is exactly where the problem lies: what would immediately jump out at everyone as “suspicious” on a real construction site obviously doesn’t in the abstract world of digital product development.
At first glance, a wireframe appears to be a self-explaining deliverable, i.e., a self-explanatory delivery module that does not require any further explanation or addition by the suppliers. But the opposite is true: a wireframe needs a lot of verbal or written explanations to be usable as a deliverable for visual designers or software engineers.
Here are just a few questions that, in my experience, the recipient always asks with any traditional wireframe delivery:
What context of use are we looking at here? What persona is interacting here right now? What happened before? Should this layout be picked up exactly the same way in the visual design, or is there free space? Are the texts and names final or will they change? What kind of information model should this wireframe be based on? What edge cases are there if the user does not follow the happy path? Which user needs are actually resolved by this wireframe? Have these user needs been validated or are they still risky assumptions? …
I could add many more questions, but I refrain from doing so in the “reader-centric” sense. And of course not only wireframes leave many questions unanswered. Other deliverables also raise many more questions. I’m concentrating so much on wireframes here because they are often consulted mono-thematically and their visual appearance even tends to hide the fact that they leave many questions unanswered.
Just delivers… models!
So if UX design can’t do without deliverables, but wireframes are really just too big, too mono-thematic, too incomplete intermediate deliveries that really need to be supplemented by much more communication or documentation… then what is the deliverable of choice?
My answer to this is: all deliverables that are merely intermediate deliveries should meet the criteria of a model. Herbert Stachowiak characterizes a model by the following three features:
1. illustration
A model always stands for something else – namely for a natural or an artificial original, which it thus depicts or represents.
2. abbreviation
A model does not capture all the attributes of the original, but only those that seem relevant to the model creators or model users.
3. pragmatism
Models are not clearly assigned to their originals. They fulfill their substitution function
for certain subjects (for whom?)
within certain time intervals (when?)
under restriction to certain mental or actual operations (what for?)
Models don’t have to please, they only have to help
The advantage of the model concept is that, in contrast to the design concept, it does not create any expectations, such as: “A deliverable always has to please in order to be useful.” (Unless, of course, one moves in the domain of the fashion industry, to which I apologize in advance at this point).
On the other hand, the concept of model already expresses by its very nature that models as deliverables building blocks are by no means about already creating reality, but merely about delivering a simplified image of reality. Models are thus suitable both for discovery processes (in the problem space) and for creation processes (in the solution space) and thus even form the bridge between two worlds.
Examples for models
A persona, for example, is already a model by definition, because every persona is an image of a person who could exist in real life and is representative of the targeted user group. However, it is perfectly okay and even recommended that the modeled person does not actually exist in real life.
In the same way, however, a “user flow” in the form of an activity diagram is also a pragmatic model, because it can thus be seen at a glance that an activity diagram models a certain workflow in possible variations without even considering the aesthetic visualization of these workflows. An activity diagram is thus victorious in all three criteria of a model (illustration, abbreviation, and pragmatism).
Wireframes, on the other hand, stumble in both abbreviation and pragmatism, because it is seldom clear which of the boxes depicted in the wireframe has which relevance, or for whom these boxes are valid at all, at what point in time, and with what restriction. For this reason, a wireframe is not understood by the stakeholders as an image worth adding to, but as a complete design artifact – with all the negative consequences already mentioned.
Conclusion: UX modelers stand up!
Obviously, there is a need for professional people who are able to deliver usable models to their colleagues. Models that shine to a high degree on all three criteria of mapping, abbreviation, and pragmatism. These people are essential to fueling the digital design process. These are the people we at Centigrade are increasingly keeping our eyes open for as well.
By “professional UX modelers” I don’t mean people who are capable of facilitating design thinking workshops or writing inspiring ideas on sticky notes, sticking them on a virtual whiteboard or even scribbling storyboards on an iPad. Of course, these are just as necessary in the design process – but they are not professional modelers!
I am interested in people who understand that models must be rich in variations and that each individual model is only one of many deliverable building blocks in the now long UX supply chain. I’m about people who understand models as something that is precise and binding and that must always be directly usable by the next in the supply chain.
But what is the name of the role that underlies this profile? I can’t say for sure yet, but I think the term UX Conceptualizer or even UX Modeler might already be a pretty good start. In the past they might have been called information architects*…. not bad either – but what is the core deliverable of information architects? Information? An information architecture? That sounds quite static and doesn’t do justice to the dynamic nature of user experience. But UX architect sounds quite appropriate…
Basically, it doesn’t matter what the profession I’m referring to might be called. In my opinion, the core tasks of the role include:
- Understanding and documenting the mental model of a target user.
- Translation between the mental models of the target users and the domain and business models of the stakeholders
- Good knowledge of the Unified Modeling Language (UML)
- Modeling of usage scenarios and use cases
- Modeling of personas and user needs
- Modeling of workflows in the form of activity diagrams and sequence diagrams
- Modeling of use-related information structures in the form of class diagrams or entity-relationship diagrams
- Modeling of system behavior in the form of state diagrams
- Collaborative support in the design of application programming interfaces (APIs) and translation into the user perspective, translator from “data-driven” to “information-driven” thus.
- Structuring and documentation of design system elements
We have aroused your interest? Take a look at our services!
