RE-DT-UX: Moving from a Discipline-Based Approach to a Role-Based One

Abstract

A lot of companies work in traditional separation of professional disciplines, also Siemens. Experts define their role by being part and fulfilling the defined pattern of this discipline. The stuffed project teams are a mix of professional disciplines. But why is your original discipline the key differentiation factor? Why not look for tool and method-driven role expertise and combine it in teams with different relevant roles for a project? What happens if you change from a disciplined view to a role-defined perspective of expert impact? What happens if we stuff agile projects in an agile manor? Which role plays design thinking for it? Find it out in the following description of a new working culture at Siemens.

Introduction

Our research group at Siemens AG is comprised of 25 User Experience Designers, Design Thinkers, and Requirements Engineers. We believe our interdisciplinary teams allow us to better serve our customers at Siemens. This is not because this might allow us to have experts focus on their specialties but because working as T-shaped teams allows us to benefit from a multitude of experiences and opinions while developing a great user experience for our software solutions. Rather than focus on our original disciplines, however, we have found that thinking in roles that can be filled by different individuals when needed allows us to better respond to quickly changing project requirements.

In this chapter, we describe how the various experience-related roles work together in our team and how we use them to best support the development of products with a positive UX.

Joining Forces to Create Offerings with Great UX

Our goal is an efficient design for offerings that create a great User Experience (UX). UX is about the entire experience in connection with the product or service under consideration. In this respect, UX encompasses more than usability or UI, where only the direct interaction is considered. The term experience implies the integration of all relevant aspects, including the information architecture, the performance, the content presented, etc. It is therefore important for us to involve the customer and all stakeholders in the design process at an early stage. The Customer Experience can already be influenced with the idea and the definition of an eco-system (for more information on this approach see Lowdermilk T and Hammontree M (2020)). This is only truly possible if we approach the user’s needs empathically from various directions.

Tim Brown who coined the term T-shaped people describes them as follows: “T-shaped people have both depth and breadth in their skills.” Rather than being only experts in their field, “the horizontal stroke of the “T” is the disposition for collaboration across disciplines. It is composed of two things. First, empathy. It is important because it allows people to imagine the problem from another perspective- to stand in somebody else’s shoes. Second, they tend to get very enthusiastic about other people’s disciplines, to the point that they may actually start to practice them” (Hansen 2010). This is what our current role-based approach at Siemens T allows us to do.

Our basic understanding as UXD at Siemens Technology is that we work in the field of customer experience management. This means that the user experience must already be taken into account while devising the business model, with the definition of the eco-system, and all other phases of the product lifecycle.

Everything is part of the whole. So, all methods and tools used serve the overarching goal of finding out the needs of the user and to find “the best fitting way” to implement them. It is important to ensure that we are talking about analyzed real user needs and not user wishes. This is where Agile RE comes into play. In Agile RE methods and best practices of traditional RE are partially incorporated into the tasks and roles of agile development without violating agile principles. Here, traditional parts of the traditional RE approach are used to increase the description quality of Epics, User Stories or Feature definition. For example, wishes identified in interviews are often equated with needs, without trying to understand the intention of the user or trying to identify the potential and tasks behind the user’s wish. This could be a user insisting that a button ‘has to be red’ and the design team blindly implementing a red button rather than asking why this is so important for the user. It is like staying at the symptom level in medicine without asking about the causes. In our button example, this could, for example, be caused by the user wanting to make sure that they always know where this specific button is located. This can be implemented with a red button but there are also other interaction and visual design choices that can fulfill the same need for safety or competence. A good user experience can arise only if we try to understand the needs behind these wishes (for more on this see Hassenzahl 2008).

Our “Old” Discipline-Based Approach

In the past, we saw ourselves as different disciplines working in one team. This included Usability Engineers, Design Thinkers, Requirements Engineers, and others.

Usability Engineer

A Usability Engineer drives the research strategy. By conducting usability studies and performing contextual inquiry he analyzes the user’s workflow. This allows him to understand the user and customer needs. The Usability Engineers is also responsible for testing. He evaluates prototypes, runs User Acceptance Tests, and performs heuristic evaluations. He is also responsible for the interaction modeling. This includes considering mental models and task models, creation of storyboards and user journey maps. After initial testing of his concepts, he also creates wireframes that visualize the concept.

Design Thinker

The goal of a design thinker is to establish a human-centered mindset within the company. They plan and execute Design Thinking projects that develop innovative products, and services. A good Design Thinker creates an understanding of a customer or user, their pains and gains, as well as their needs. They do so through empathy building and use those insights to iteratively generate ideas for innovative concepts that are tailored to user’s needs.

Requirements Engineer

In our understanding, a traditional Requirements Engineer’s main task is to establish a common understanding between the stakeholders of the project. He not only bridges the gap between business and technology, but also reaches out for the agreement between all involved parties. In agile teams, he accompanies and supports the design sprints from Design Thinking, while, for example, applying and enforcing traditional RE best practices, like precise, testable statements and using the artifacts created in a structured way.

As more and more of our Siemens internal customers started adopting agile, some even moving to DevOps, we noticed that this discipline-focused approach was not serving us well. Therefore, we made the shift towards a role-based approach.

Why We Need a Unified Approach

When it comes to Agile SW-development, tasks and responsibilities associated with development are typically distributed over different development team members by roles. Besides developers, typically roles in the projects we work on include Product Owner, Architect, Requirements Engineer, User Experience Designer and of course others. However, due to the ever shorter release cycles of SW-Products releases, we have observed and experienced the following pitfalls, both within and outside our organization, that work against our goal of creating great UX. In this section, we will describe these pitfalls and how they affect the overall development goal.

No or Very Limited Market(segment) (Over)view, No Business Model, No Bundling, Vision and Scope (V&S) Not Existent or Not Agreed, Stakeholders Not Fully Interviewed

Some products that are being developed are technological solutions but do not address a specific market/customer/user need and do not have a vision of what they are trying to address. The general development approach itself, be it Agile, Scrum, SAFe™ or DevOps is often used as an excuse for not applying certain development best practices. For example, not fully described and agreed on, realistic and believable project vision exists between stakeholders and team members. Therefore, there is also no clear scoping of such a vision with respect to a given market or customer. On the contrary, the market and customers segments have not been investigated thoroughly, described and neither is the resulting product agreed to be positioned well within the known market. This often means no business model is defined and described and its interaction with the intended product/customer is therefore unclear and the overall applicability has not been thought through. This would not be a problem if there was a single strong product visionary/product lead. In some projects, even if benchmarks and market research are performed, they are not shared with the project team in the project context with respect to the product’s features and unique selling points. On the contrary, often due to department splits or responsibility splits also little to nothing is described with the respective domain expertise at hand. This means the positioning of the product with its intended features and bundling is completely unclear beforehand. All this often results also in no pilot or lead customer being included in the project, more or less leading into the next area of problems.

Non-existing Lead or Insufficient Customer Availability

This lack of research or overview in turn often leads to an unclear mission statement of the project’s development goals and no real timelines that can be addressed by an Agile development methodology. This is complicated further if sprints are conducted delivering features of unclear customer value. Furthermore, in today’s projects, some crucial aspects and preconditions necessary for a truly Agile development approach are often not met. For example, the customer is not at all or not really permanently on board, thus resulting in the development team being unable to resolve issues. This results in time delays or the team making decisions. Overall, this makes the work of the UX Researcher infinitely harder since it is that much harder to develop insights on development results Of course, one could argue that the Agile approach has a fail-safe for this at demos and that deliveries can still be rejected. Nevertheless, in larger organizations, this leads to huge inefficiencies and other roles taking over the roles of customer or even product owner often leading to sub-optimal decisions.

Missing Domain Experience and Domain Expertise

Often enough, the person executing the role of Product Owner is also unsure in details of the domain and thus not able to resolve such questions either. In some cases, product ownership is not associated with deep domain knowledge. Hence the product owner also needs to rely on the results from User Research which are hampered by the lack of access to users. Typically, this deficit in domain expertise leads also to the requests of Product Owners towards architects to decide on the product’s functions and features via selection of technologies/components. This approach automatically limits the feasibility and applicability of the product’s solution scope. Alternatively, the burden falls on Requirement Engineers to define the functionality with some creativity at hand. Especially in projects when UX is only included once development has already started this means it is often too late to make changes in features and functions that drastically affect the underlying architecture.

Missing Customer Insights: User Experience Not Investigated Due to Misprioritization, Too Little Knowledge on Importance of UX

Last but not least the lack of awareness for the insight of customers’ real wishes and needs and their intended interaction ala Design Thinking or the elaboration and design of customer experience in an Agile manner is often neglected either due to time pressure, the team not being able to apply the methods, not knowing them at all or the misfit of such methods with existing roles and the development approach. This could be that no UX expert is part of the development team or the methods required do not fit into the sprints. This often means even if they are applied, there is not enough time to deliver the intended improvement in the product’s interaction design and the resulting user experience.

Missing Strong Lead/Visionary

All of these described pitfalls probably would not derail a project if there was a strong lead or visionary, vouching with single responsibility for the product’s vision, scope, and technology to be developed/applied, like Steve Job’s iPhone idea, and willing to accept and carry the associated development risk, having entrepreneurial spirit and taking the necessary involved business risk from cradle to grave. Such a single strong product lead role typically does not exist in a large organization’s development either. Rather, there is a split of associated responsibilities over several departments, roles, or boards as well as risk averseness, in combination counteracting real Agility. Not to mention, political aspects such as the blocking of knowledge between organizational units. Most often, we do, however, simply observe a lack of time for intense, continuous collaboration between different organizations/departments like marketing, sales, and development.

While we cannot single-handedly address all these pitfalls, we have noticed that making small changes in how we, as a team, work in agile projects can lessen their effect.

A Role-Based Approach

Our experience over the past two decades has been that agility has changed our work environment dramatically. In a way, software development’s mindset has moved closer to our mindset. At the same time, strategies that allowed for an integration of Requirements Engineering, Design Thinking, and User Experience into the development process have become harder to implement, if not obsolete. We have found that shifting to a role-based approach has helped us adjust to this change in our environment as well as tackle the challenges we observe in agile SW development. Figure 1 shows the different roles we work with. Note, that not all roles are present in every project, and we also have times when not all roles are filled within our research group, but we believe that they all play their role in delivering great UX.

Fig. 1

This diagram shows the different specialties that work together to create great user experience

Figure 1 describes the different roles we use. Generally, they can be grouped based on their focus. The first is on the What (“What should be developed?”). These roles are especially active at earlier phases of product development. These roles are Experience Analyst, User Researcher, Business Analyst, Information Architect and Content Strategist. Somewhere in the middle, we have our UX Strategists. The other focus is that on How (“How should the thing that is being developed look and interact?”). These roles are more active during the elaboration and construction phases of a project. These roles include Interaction Designer, Accessibility, Visual Designer, Front-End-Developer, and UX Tester.

How They Work Together

By differentiating between these roles, we can then make it explicit how and when they work together when developing products. If you take the average architectural process (see Fig. 2), not all Roles are always equally active during the process and not all projects require all roles to work on them.

Fig. 2

The different roles work together throughout the development process. Restricted | © Siemens 2020

While the different roles work together one or two roles tend to be in the lead at a given time.

If you take the initiation phase of the project pictured in Fig. 2. In the Understand phase, User Researcher, UX Strategist and Business Analyst work together to develop a vision. The different roles do not have to rely on different methods but can focus on different aspects of the process. For example, the User Researcher collects information about user needs in interviews or observations that the UX Strategist might use to glean important strategic insights when combined with other pieces of information. The results of the methods employed in the understand phase are used by the roles involved in later phases. In the next phase, the Experience Analyst drives innovation to support the development of an opportunity statement that actually creates impact. This could be in co-creation sessions or in more “classical” DT workshops. Next, the Information Architect focuses on requirements that can then be used as input by Experience Analysts and UX Strategists to create concrete ideas for the product definition. Amongst other methods brainstorming and ideation methods come to fruition here. The ideas created in this phase can then be checked by the Content Strategist and Accessibility. At this stage User stories are defined and the first low-fidelity prototypes are developed before being initially evaluated by the UX Tester.

After this first evaluation loop, the other roles focused on the How to become much more active. The Interaction Designer develops interaction concepts while the Visual Designer defines UI patterns. This is followed by the development of wireframes from the Interaction Designer while the Visual Designer works on the UI concept and design.

Here they are being supported again by the UX Tester and Accessibility who evaluate the increasingly high-fidelity prototypes with users.

At this point, development is in full swing and the evaluated mock-ups are being implemented this means after this evaluation loop, if not before the Frontend Developer becomes active and starts building the frontend while the Visual Designer continues working on the visual design. At this point, we are normally sprinting together with the development teams and most often use a one-sprint-ahead approach (Alt-Simmons 2015) if we are not more systematically integrated either through Dual Track (Sy 2007) or a framework such as SAFe™ (Knaster and Leffingwell 2020).

There are two/four other roles that were not included in Fig. 1 which both become relevant if we are supporting agile release trains. Those roles are the Technical Product Owner (TPO) Design Product Owner (DPO) as well as their Project Management Office (e.g., PMO Design) counterparts. With these roles, the other roles are directly embedded in the agile development process. The TPO, for example, not only interfaces the gap between business and technology, but also reaches out for the agreement between all involved parties with agile methods. Along the line he accompanies and supports the design sprints from Design Thinking, while, for example, applying and enforcing traditional RE best practices, like precise, testable statements and using the artifacts created in a structured way. The TPO keeps the overview and manages all agilely created artifacts, that are in later stages of development the basis for further planning, managing, and execution of the project.

This integration of UX roles into the development process allows us to leverage the benefits of both agile development and human-centered design without sacrificing one for the sake of the other.

Conclusion

The working world at Siemens is constantly changing and must also cover various customer requirements. Our UX department at Siemens Technology has been for more than 25 years, and a lot has changed here too since it started with Ergonomics evaluations. It has become a central hub for UX in the Company and is offering UX consulting services to the different business units.

If you look on our Siemens—internal understanding of UX—you see a huge number of different roles. How does that influence our work? We no longer discuss various disciplines like: Design Thinking vs. Requirements Engineering. We try to avoid these terms. With a focus on the tasks of each team member and the role he/she is playing in a specific project—we gain a better understanding of the interaction with the customer and better support from the business. The roles enable us to match better to standard IT approaches (like PO/TPO/DPO/etc.), and the roles give a clear frame of responsibilities and more transparency for business partners. Another relevant point is the situation, that a UX team member can own different roles—in dependence on his expertise. The focus of the ongoing project defines his primary role.

Talking about roles makes it easier to see oneself as a part of the UX team instead of being an expert in the UX team. Growing together as a UX team means also to learn from each other. In practice, we very often use the power of a 2-expertises-UX-consulting. That means we try to integrate at least 2 UX roles into a project. That gives the 2 UX Experts the possibility to work on the same project and exchange the different expert views, plan together the usage of methods and discuss about pros/cons and expected results. With this strategy, we strengthen the expertise of the whole UX team, avoid discipline boundaries and deliver the best possible result for the customer. These working procedures enable us to support the customer with a long-term and high quality UX consulting expertise along the product definition and product development process.

Over the last few years, this has opened the doors to very early integration into the product definition phase, we are now a partner for the development phase and work with and in development teams. Being a partner in the development process—and not only a temporarily expert—that was the target we were aiming to achieve with this approach.

Outlook

You might ask where we want to focus next. These days, it is more essential than ever before, to communicate, to build expert communities inside the company and to coordinate the own work with inner source models, internal exchange events and support of ongoing learning like a weekly best-practice exchange. We believe these kinds of activities allow us to increase the UX maturity of our entire corporation. Our UX department is realizing this in our UX CAMP. UX Camp is a creative space but also a virtual UX community hub. We offer weekly Best-Practice-Exchange, free “first-aid” support, regularly events for experts and management, and free usable method sources for all business departments inside Siemens. This affects a growing UX culture, growing UX maturity and over all the focus on customer needs and values.