Purchase a soft copy on Lulu.com for $74.90.
Posts
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!
By Helmut Degen – June 4, 2021 – 1 minute read
I am very proud to have contributed to the book “97 things every UX practitioner should know”, published by O’Reilly. Kudos to Dan Berlin, the founder and CEO of Watch City Research in Boston, MA for herding 97 UX cats from around the world.
My short chapter is about the use of design goals, which are called “Involvement Goals” in the elaborated approach “Experience Architecture and Design for Efficiency”.
There are 96 other great tips and tricks in the book, worthwhile to read, so don’t hesitate to receive a copy of the book.
By Helmut Degen – June 3, 2021 – 2 minute read
After a break from being present online for quite some time, I want to let you know that I have added a lot of content under the new section “Tools and Template”. This is still going this week for the next couple of weeks. So, don’t be surprise if you see content tomorrow which wasn’t there today, and the other way around (he he).
Tutorial on July 28, 2021, 8am – 12pm (EDT) as a virtual event
I’ll facilitate a tutorial on July 28, 2021, 8am – 12pm (EDT) as a virtual event. The concepts will see the light of the day and the faces of my fellow colleagues. Seats are still available, of course. Actually, I hope that a few people will sign up.
Updates to the content: Experience Architecture
The section “Tools and Template” is organized into three parts (you can read here more):
- Overview about Experience Architecture and Experience Design, and their overlap
- Experience Architecture
- Experience Design
I am curious to hear feedback about the section “Experience Architecture”. Experience Architecture (ExA) is a relative new concept. It is necessary due to the growing complexity of systems and user involvement. It is also necessary for efficiency considerations. Up to this point, we have already made significant decisions, before we come to even think about screens and interaction elements.
Even if Experience Design (ExD) is more established, I am sure the way it is described here is new for some of my fellow colleagues. The twelve efficiency technique help to systematically optimize an involvement concept for efficiency. Also here, if you have feedback, don’t be shy.
Book launch delayed for another six month or so
Although the book isn’t ready yet (I’ll give it another six month or so), I’ll put most relevant content out here. Is the content practical? You bet, I’ll use it in all of my projects, and my stakeholders love it.
That’s enough for today. Enjoy a peaceful, healthy and safe summer.
I am writing right now the book “Design for Efficiency” and I treat the book like a design book. It is planned to involve the future readers during the creation process and incorporate their feedback. Can this work?
By Helmut Degen – March 21, 2020 – 4 min read
This happened to be like with many of us (designers), I believe. There is an initial idea, small and vulnerable. The idea found its way into my head, and I started playing with it, like throwing a tennis ball against a wall – back and forth. Over time, the idea becomes more steady, and at some point in time, I couldn’t ignore it anymore.
In my case, it is a book about “Design for Efficiency”, a topic which I nurture for some time. I started to look into the topic. I was searching for material, online and offline, and was initially surprised that I couldn’t find anything of useful. So I started to develop my own toolbox and applied the tools in my design projects … and then I though: where a gap is, there is an opportunity.
Who inspired me?
After I decided to write the book (which I thought was already a courageous idea), I went even further. Over the last holiday break, I was contemplating about the distribution. My son told me about a professor, actually a couple, from Wisconsin. Their names are Remzi H. Arpaci-Dusseau and Adrea C. Arpaci-Dusseau. Due to the lack of appropriate text books for Operating Systems, they started writing their own text book. After they finalized it, the distribute it on their website Operationg Systems: Three Easy Pieces. Each chapter is available for free as a PDF; the entire book as a PDF costs $10 and there are soft copies and hard copies available on Amazon and Lulu (as a hard copy and as a soft copy). I was very much impressed by their reach – more than half a million downloads. I know, a professional is not a professor, however …
What about feedback?
I make my living with design for industrial applications, and involvement of users (or their proxies) is part of my working style. If you publish something, feedback is unavoidable. The question is: which feedback is more helpful. Receiving feedback after the launch is good, and you can learn something for the next project … maybe. Feedback prior to the launch is better, so that the book can be improved before it gets published.
What about publishers?
If the text is pre-published, publishers won’t accept it anymore. However, the real question is not “what about publishers?”. Publishing houses are just a means for something. The real question is: How to measure success of the book? I took money out of the equation. Eventually, I came to the following success criterion: adoption. I believe the design discipline is currently on a beautification path, and “design for efficiency” may have some corrective influence. So, adoption it is. The target audience are professionals (they have disposable money) and students (they don’t). Therefore, I decided to give it away for free. The only problem with adoption is – the content isn’t relevant or good enough. I like that challenge, it keeps my fingers on the toes or keyboards.
What about the topic “design for efficiency”?
That’s a good question. Efficiency is almost an ancient part of usability, going back to the 90s. After I did some research, I get the impression that efficiency is not really a design focus. We still swing between effectiveness and delight. I personally respect time a lot. It is the most precious resource we have, as human beings. Design for efficiency shows respect for the time of our users. Here is a diagram which I use in the book. It shows the benefits of making time disposable.
What about involving the UX community to provide feedback?
Is someone willing to read a book concept, not the final book, and to provide feedback in their spare time and for free? Will this work? I don’t know. I hope I can find a few colleagues, students and teachers (yes, you all belong to the audience) who are willing to provide feedback. What is the return? A better book.
Do the test readers get a discount later on?
The simple answer is: No! The better answer is: everyone gets a discount. The book will be available for free. I hope this is motivation to find a few colleagues which might be willing to spend a bit of time.
Can it work? I am mildly optimistic, and time will tell. I am going to share the progress here.