Anne Hess is a researcher at the Fraunhofer Institute for Experimental Software Engineering. As part of the interview series UX Neu Überdacht, she and Thomas Immich talk in the Outdoor Office about modern requirements engineering and creative approaches, how to get richer information from users, and which methods from disciplines outside the field can inspire and inspire UX professionals to become better.
For further reading, here is a paper by Anne Hess on exciting, alternative RE approaches: Conspiracy Walls in Requirements Engineering – Analyzing Requirements like a Detective
Interview about Continuous UX and Requirements Engineering
Anne: From a UX perspective, where do requirements come from, specifically user requirements? What elicitation techniques are used, what works well, what doesn’t work well? We have a wide variety of questions about this, which we have grouped into different topic blocks. Can you pick a project from your work that we can use to discuss these questions? At best, a project where the requirements came from the customer or stakeholders and then they were implemented in a corresponding solution. Then I would like to be more specific about the roles in the team that implemented the project.
Thomas: I’ll take an anonymous project from the financial industry. It was a UX design project with a team of six people at Centigrade: a user researcher, two front-end engineers, a visual designer, a concept designer, and me in project management. In addition, there was the team on the client side.
Anne: So those were the roles you worked with intensively throughout the project?
Thomas: Exactly. But the intensity of the collaboration depended more on the phase of the project we were in. Ideally, you would like to have all the people involved at all times. But from an economic point of view, that doesn’t make sense. That’s why we always try to achieve an efficient overlap of the various disciplines. At the beginning, when the product is still in the discovery phase and depends more on the user research results, user research and concept design overlap very strongly and find their common ground in requirements engineering. When you can go more into prototyping within the product discovery phase, concept design and visual design overlap. And then, when it goes into implementation and it moves from discovery more into continuous delivery, visual design and software engineering overlap with concept design. So we try to bring the right baton to the right colleague at the right moment, so that they get the necessary knowledge and in turn pass the baton on again.
Anne: I see. That means you were involved as a product owner throughout all phases?
Thomas: No, not as product owner, but as UX manager, since product ownership often lies with the customer. That means, unless the customer explicitly wants it differently, we don’t make strategic specifications like a PO often does, but rather ask about the circumstances, classify them from a user-centric perspective and support prioritization. So we don’t want to directly dictate which backlog item belongs up or down, but rather make informed recommendations based on user research findings. We can of course argue why we think a certain direction makes sense for users*, but ultimately we all always have to ask ourselves the question “What business value does the company want to achieve using UX from a strategic perspective?” Only the customer themselves can answer this question. That’s why the PO role is almost exclusively with the customer. So we see the UX Manager role as an accompanying, assisting role for the PO: the UX Manager, unlike the PO, has to make sure that the trades mesh, that they are hand-off-able, and that they are based on real user research insights. So that was also my role as the UX Manager of the project I was talking about.
Anne: And other than the PO on the client side, were there any other roles that you interacted with?
Thomas: Yes, on this particular project there were actually quite a few. There was a dedicated project manager in addition to the PO to manage the project and keep track of resources and budgets. There was also a domain expert, sometimes called a “subject matter expert” or “business analyst,” specifically for the financial industry, a small assistant team of student workers for user needs and marketing research, and a software architect who knew the customer’s entire IT infrastructure like the back of his hand.
Anne: What were the primary sources you got your requirements from?
Thomas: Since it was a large financial institution, there was of course a dedicated marketing department that had already segmented marketing personas into milieus and generations in advance. But these kinds of profiles, á la Millenials vs. Generation Y were still too rough for the UX work.
Therefore, we in the Centigrade team led user research activities, conducted interviews, browsed forums, and did specific research on user forums, for example. For example, we read through how our target audience prepares for when they first become business savvy at 18. We took a deeper look at these and other key life situations to figure out when which user experience would best reach which target group.
Fortunately, there were also many volunteers in this group for this who said, I’ll get in touch as a potential customer and tell you about my life.
We asked these people a lot of solution-independent questions, such as: “What was it like when you came of age, when you had your first account?”, “What did that do to you, suddenly being of age?” and so on.
Anne: That means you studied the as-is situation and didn’t get any concrete functional requirements from the customer?
Thomas: Exactly, requirements analysis is primarily about describing life situations in the form of so-called usage scenarios. An exemplary life situation would be, for example, that the vacation of a couple with offspring has to be financed. The couple does not yet know how many expenses they can expect with a child. The couple cannot yet calculate what they can afford. They need another apartment, but they are still too young to be creditworthy. This is one of the many exemplary places where new CX or UX solutions can deliver real added value. There is obviously great potential behind the linking of the topics of housing, travel and financing when it comes to offering helpful support as a financial institution for the set target group.
We then derived so-called user needs from usage scenarios. Basically, these are non-verified assumptions about what specific user needs exist in different contexts.
Anne: Did you validate the user needs with the users?
Thomas: First of all, we just verified them using user research. By going into conversation or observation with users, we get concrete evidence about whether what we assume to be a requirement is correct. Verification then turns the informal, unverified user needs as pure assumptions into user stories, i.e. real user requirements.
Anne: And that verification, does one particular person do that and then you guys shared or did everybody do a little bit of research and you put your findings together?
Thomas: It’s usually two people that go into user research. We deliberately want an overlap of user researcher and concept designer here. However, the user researcher then has the lead. In this case, it was a psychologist who brought the concept designer on board, so that the two of them formed a small team for the short verification phase; the user researcher focuses more on the problem space, the concept designer more on the solution space.
For us, user research is a purely reading discipline. It does not design, it questions. It turns over stones. It looks behind the scenes, but it does not put ideas into the world. I think this hard separation is important. As much as I strive with Continuous UX for all the trades to ultimately flow into each other, at the end of the day, you should never test what you’ve designed. That’s why I’m in favor of a separation of powers.
Anne: The user researcher was a psychologist. Is it always psychologists that do this work for you guys? What other educational backgrounds are there?
Thomas: Yes, that is almost exclusively the case with us. If it’s not pure psychologists, then it’s at least a computer science education with psychology as a minor, which is now called cognitive science at the University of Duisburg-Essen, for example. There you get enough psychological background to be effective in user research.
Anne: Despite the deep user analysis, were creativity techniques and design thinking used in this project? How is something like this typically done and who is responsible for it?
Thomas: Yes! With the arrival of the first user research insights, we move into the ideation phase. Here again, the conceptual designer is in the lead and triggers the creative impulses. However, he limits himself to the problem space defined by the user researcher. We always see creativity as particularly lively when the space in which one moves is as limited as possible and not when it is too open. We go into ideation workshops with about 3 user stories. These may describe just 4 minutes in the life of the user and yet they often ignite a firework of ideas. All ideas are allowed, but only if they fit the context of the selected user stories. If an idea is not technically feasible, it is still allowed in. The doubting engineer in this case may then at most suggest another idea that is even easier to implement, but not destroy the original idea. Software engineers are explicitly welcome in this format!
Anne: You have a whole portfolio of techniques to elicit requirements. When a new project comes in, do you do any planning at the beginning about what methods you’re going to use? And if so, what are factors that influence that choice?
Thomas: We try to pick the best methods and work with the same methods over and over again, if possible. Because I think that even a good method produces a bad result if there is no routine there. That is, you can of course always choose from a bouquet of methods, but, if you don’t use the chosen methods constantly every day, they may bring you new inspiration, but not that professional routine to be effective and efficient. A visual designer won’t think of constantly changing their design tools either. There are skills that you create on top of all the time. Of course, you can’t stand still and you have to keep your eyes open left and right along the way. But you also have to bring a routine with you.
Anne: What works particularly well for you in requirements gathering?
Thomas: I think what we manage very well is to narrow down the context of use hard and prevent “scope creep”. That’s why we call the user research “scoped user research”, i.e. user research with a limited scope. You can easily start your user research, drive into a machine shop and return half-beaten by 1,001 impressions. You can talk to any number of users there, but you can’t fill as many notebooks as you take away with you. And what do you do with them? You or your colleagues don’t even get to process it.
In Scoped User Research, we therefore explicitly determine in advance what the usage scenario is that promises the highest business added value. We determine in advance which are our key personas and our most important user needs, and then we look at these in detail via interview or observation. Of course, users also sometimes tell us about other exciting things, but we try to park this for later or to take it along as a “feeling” without having to deal with it in more detail. We put our finger on those points that are predetermined by the usage scenario. And this scenario is always very tightly formulated, which is why we usually get there in a day or two.
Anne: Where do you see problems or challenges in elicitation?
Thomas: The biggest challenge in requirements engineering is documenting requirements in such a way that someone who has not been there from the beginning understands them correctly. I haven’t found the sweet spot there myself yet. What is too much, what is too little documentation? Sometimes I hear software engineers, for example, say, “I don’t care what the persona is. I just want to know what to develop now.” I’m skeptical about that being a good attitude. I think everyone in a frontend-oriented development team has to want to think UX, and this is where you then have to force the software engineers’ luck a bit, for example by inviting them to the idea workshop where the persona is presented big and wide at the beginning. This makes the challenge much smaller at the end. In addition, people are always sick or the team gets new members or whatever. And how do you communicate to this newcomer in a short time what the problem actually is, if you have no documentation to fall back on? That is extremely difficult. Basically, we at Centigrade invented the Continuous UX toolkit only so that we can always deliver reproducible quality despite the many external changes that an agency always has, i.e. client size, team constellations, UX maturity, degree of agility, etc. I think our success with a wide variety of global market leaders, as well as numerous design awards, show that this was a really good investment.
Anne: We’ve heard about personas, scenarios, user needs, user stories, but I also found the user booklets you keep mentioning in the context of Continuous UX exciting. Can you talk more about that?
Thomas: The user booklet method is all about exchanging user-centric artifacts such as user research findings, concept ideas or screen mocks between interdisciplinary team members as quickly as possible.
After all, many people do the pure “dump in requirements data” thing. Many dump data into Confluence or any other wiki. But what happens to this data? Nothing, unless the next person can also consume it. Therefore, we successively enrich each user story with only the information that is relevant in this context. We don’t dump all user research results into one folder and all Figma prototypes into the other. We explicitly document only those artifacts that are relevant for a specific user in a specific context of use. For example, someone new to the team can jump directly from a particular solution idea back to its origin and motivation.
We also automatically generate posters and stories from our requirements data that quickly pick up others at a high fluency level. We create exciting stakeholder infographics at the push of a button that reveal at a glance which stakeholders are end users and which are purchase decision makers, or even both. We use the LeanScope software tool for this, which is perfect for storytelling-based requirements engineering as well as for the user booklet method.
Anne: Do you always play back anything that comes up during project retrospectives?
Thomas: Of course! You can sometimes get a lot wrong before a project really goes bang. But then it’s usually a foregone conclusion and it really pops. Unfortunately, you can also do a lot right and it still goes bang! Therefore, it is important to observe what worked well in detail in a project and what did not. And what of it can be generalized and what of it can simply be attributed to the project constellation.
I see the Continuous UX toolkit like a versioned product. With each project, a small version number is added and we release our new Continuous UX playbook. And so we keep developing automatically and Continuous UX gets evolutionarily better with every day.
Anne: What is the greatest challenge when implementing requirements?
Thomas: The supreme discipline is to make the leap from design to engineering. It’s just incredibly difficult because it’s so often mutually dependent. Do you always bring in all the software engineers from the beginning and then suddenly they’re all designers? Or do you bring the designers in at the beginning and the engineers a little bit later, but then the acceptance of the software engineers goes down the drain? We believe that it is good to involve software engineers early on and see them as sparring partners for the designers. At the end of the day, I also always say: designers are also developers, just like engineers. That’s the way it’s always been in the video game industry… and that’s where I come from.
Anne: You guys work closely together spatially here. How does the typical communication work?
Thomas: We see collaborative workshops with clients as a pillar of our Continuous UX process. They’re unmovable. It starts with the scoping workshop, then we go into the ideation workshop, and so on. There are these workshops to synchronize between teams and they are face-to-face whenever possible, but since Corona they also work wonderfully remotely. In between the workshops, the disciplines get active, create their artifacts and collect them in the user booklets. The workshops are therefore small structure-giving stations, and in between there is sometimes freestyle on a professional level. But there is always a continuous exchange with a clearly defined goal. This helps all team members to grow together instead of thinking in silos.
