By Helmut Degen – June 13, 2021 – 4 minute read
The short cut hunters and the value creators
Working in industry means working under a lot of time pressure. I am sure you met John “the shortcut hunter” McLean in one of your projects. John is a project manager and always looking for ways to streamline the project, reduce the project budget and timeline.
Shortcut hunters are very busy, and they would dominate a project if there wasn’t another strong role in a project: Cate “the value creator” Foresight. Cate is looking into things which are necessary for a sustainable value proposition. Unfortunately, professional shortcut hunter wins a budget argument very often. The argument typically goes like this: Cate to John: “We need budget for ‘it’.” John: “Do you delivery ‘it’ with MVP 1?” Cate: “Not really, but we need it for MVP 2 …” John: “You said it Cate, so it’s out.” Cate: “There isn’t enough time to add it to MPV 2, if we don’t start working right now.” John: “No budget, sorry.” I should add that he doesn’t really mean that he is sorry. It is not personal but is not sorry either. It’s just a set phrase.
What does this have to do with user roles and design decisions (yep, check the title)? At least, I would say, everything. Working in industrial projects, man project stakeholders consider experience contributions as beautification or brandification of user interfaces. We call the design by engineers an “engineering design”. I love this term. It is non-judgmental and still hits the nail on its head. Dieter Rams uses the term in one of his books.
So here are John’s questions: Q.1 Why do we need to elicit user roles before creating a mockup? Q.2 Why do we need to create different sets of mockups for different user roles? Q.3 Why can’t we start with one set of mockups or user interfaces, without having user roles defined? By answering the questions, I want to give Cate “the value creator” Foresight some ammunition to answer John’s question.
Graphical user interfaces are not posters
When it comes to GUIs, there is a huge misunderstanding. Many people think that user interfaces are static. They think they are like posters which you can put on your wall. Remember the posters of music bands, musicians, soccer, or baseball players or whatever group of people you adored when you were a kid or a teenager. When you grow older, you probably replaced them with the grown-up versions, like posters of architectures, operas, famous paintings or sculptures, or a museum exhibition. It may even be a poster with a popular advertisement, or a mixture of both – like the one Andy Warhol made with the soup cans in the sixties.
What is a poster, or an image in general? It is a visualized snapshot of someone or something. It is static, it may become dynamic in the mind of the observer. This is very different for a user interface, and I mean here graphical user interfaces. Even if there are difference, it is always good practice to start with the communalities. Graphical user interfaces are visualizations too. You can print and frame them, and hang them on a wall. We need to design them, like posters. And they are also time dependent: a GUI from twenty years ago looks different than a GUI from today.
Now, let’s talk about differences. There are a few important once. One is that the user interfaces are dynamic. It means that certain parts of the user interface, typically content and control elements (e.g., button, radio buttons, text fields) change. Controls allow GUIs to receive inputs from users. After a graphical user interface has received user input and the user triggers a control (e.g., OK or Submit button), the technical elements including the frontend and backend behind the GUI process the user inputs, creates an output and updates the GUI as a response, accordingly. The user repeats such steps, until the intended goal is achieved. The GUI does not only have a space dimension, but also a time dimension. The GUI is more like a movie than a still image. The gear image below shows the dependency between the goal, the user, the GUI, the frontend, and the backend.
A user role is a foundational element for design decisions
The gear image intents to show that dynamic aspect of a GUIs. I use here a mechanical gear metaphor to emphasize the dynamic dependencies between the technical elements and the GUI (blue gears) on one hand and the user and the goal (brown gears) on the other hand. The GUI presents an initial visual to the user. The user can then enter content and submit that content to the technical system. The technical system processes that content and updates the GUI with the system’s response. The user can then perform the next step, until the defined goal is achieved.
The user role with the user goals is one of the two foundational elements for any design decisions. One is the business model, the other one is the user role profile. The design decisions are the cap stone of that bridge, connecting the business needs with the user needs.
A user role profile as an effective format to document a user role. The user role profile is broader than a Persona format, on purpose, to cover the entire user population per user role. An example is shown below.
The gear image also shows that the design and development process should start with the user role profile and goal, followed by the experience design, followed by technical decisions. Otherwise, we have a wonderful engineering design which most like will not unable to support the user in achieving the goal.
Let’s answer John’s questions
Now, let’s go back to John’s interest to cut the user role definition. John had three question. Let’s answer them question by question.
Q.1 Why do we need to elicit user roles before creating a mockup? If we do not define the user role, we do not know what the user goals are and which steps the user would like to perform to achieve the goals. We miss foundational information to create a mockup.
Q.2 Why do we need to create different sets of mockups for different user roles? Each user role has different goals. Differences in goals are the reasons why we have different user groups. If the goals are different, the steps will be different to achieve the goals. Therefore, we need different mockups which support the steps to achieve the different goals for the different user roles.
Q.3 Why can’t we just start with one set of mockups or user interfaces, without having user roles defined? We can do it, but that would be dangerous and unprofessional. It is dangerous because we communicate to project stakeholders that the mockups have some validity which they don’t have. It is unprofessional because we communicate that we can make design decisions without the user role profile. We cannot.
If user roles are not defined, it is best not to make any design decisions. They became arbitrary and are neither explainable nor defendable. The user role profile is the foundation for design decisions. Would you build a house without a foundation? The same answer applies to the question: Should I build a user interface without a user role profile? The answer is simple. No! If user role profiles are cut, the success of the entire project is at risk.
So, Cate is right: user roles cannot be cut. Sorry, John!