No good project was ever done alone. “Teamwork makes the dream work,” goes the saying, but the message is there: in order for us to design and develop a great service, all different actors must work together in unison, following a shared vision toward the goal. That being said, working together, or being agile for that matter, doesn’t mean that everybody does everything. Instead, each person gives their input through their respective expertise.
At Wunder, we pride ourselves in developing smart services that actually serve both the purpose and the people it’s made for. To achieve this goal, all team members must understand not only their own tasks but the bigger picture as well, regardless of their individual role(s) in the project. Trusting each other’s expertise, strong psychological safety, and the humble curiosity to ask the seemingly “stupid” questions is key to making the most out of mutual consultation. However, crucially invaluable expertise is by no means limited to the project team. This is why both users and the client are always deeply involved in the process as well, both as teachers and students. The best part? Our clients and the users get to enjoy the results of service development that is much more than the sum of its parts. So let’s have a deeper look at the roles and their respective responsibilities within the project team, how they interact, and what value they deliver to each other’s work and overall project outcome.
And if any of the terms feel unfamiliar to you, feel free to check them out in our Service design terminology section.
Roles in the team
According to Scrum, the optimal size of a project development team is seven people. Still, for a larger project, there might be a need for consultancy or input from many more experts, or for a smaller project – one expert could cover several roles.
As stated, the magic behind a successful project is teamwork. At Wunder, we like to think that there should be (in addition to our team, of course) at least two other parties involved in a service development project: the client and the users. However, as no two projects are alike and both resources and needs vary from one to the other, it’s best not to cling to titles too much but instead examine the various roles and perspectives one might encounter in a general service development project.
In the following sections, we will examine a bit more closely the definitions of some of the most common roles and responsibilities of the Client, User, and Development team.
Client – a legal person (private adult individual, company, organization, etc.) who purchases the service or product from a service provider/development partner
Product owner – a client representative who is responsible for the goals of the product and coordination of the delivery queue and project development on the client’s side.
Other responsibilities to be allocated by the client:
- A person in charge of acceptance testing the solutions developed or designed by the project development team,
- A person in charge of providing ticket/task-specific requirements and so on to the development team,
- A person in charge of content management,
- A person in charge of brand identity,
- A contact person/link to possible experience experts, user focus groups, and/or other stakeholders.
The client’s titles, roles, and responsibilities are heavily dependent on the client organization’s internal processes; therefore, it is impossible to define them conclusively. Some responsibilities are mandatory; however, for example, clear and allocated product ownership is vital for the success of the project itself.
Disclaimer: User roles can be used on many occasions. Usually, we talk about system-level user roles, but the human relationship to service can also be described as “user”.
Customer – a consumer who interacts with the service interface and generates possible monetary value to the organization offering the service/product. Also used to describe a user in terms of how they form a relationship with the organization/brand through interacting with the service’s interface.
End-user – a person who interacts with the service user interface, i.e., perceives the service’s “front stage” actions. Refers to users outside the organization with limited access to the service or a person who the service is targeted for or is intended to ultimately use a product. It can be used to describe either targeted users or the “general public” with access to the service either through public or privacy-encrypted channels.
Experience expert – a person (usually a user derived from the target group’s user pool) with both knowledge about and first-hand experience from the users’ point of view. A valuable resource in designing services that enable great user experience as they can give insights about the user’s point of view, motivations, needs, and emotions even if there is no budget or time to conduct more thorough user research.
Internal user – editors, admins, or content creators interacting with the service’s backstage CMS
Stakeholder – a person, group, or organization that is directly or indirectly involved or affected to, or has an interest in the outcomes of a particular service.
User – a general term for anyone who interacts with the interface (usually used to refer to end-users instead of internal users).
“The User” (in the irony of the title) as a role is often considered as a rather passive, even objectified aspect of service development existing “outside” the project team itself. At Wunder, however, we believe that users are and should be celebrated as both a rich value resource and an important player within the project team itself. Users, both internal, such as editors and content creators, and external, such as end-users or customers, are able to test solutions, give feedback on them, and most importantly, give precious insights about what problems or needs they have regarding the end result.
Development team roles
Project/Account management – includes roles such as account, project, and delivery managers; responsible for the development team resourcing and value delivery and managing the development queue alongside the product owner.
Service Designer – an expert in design thinking who guides the client and team to see and think about the service or technical solution as a part of a bigger, human-centered picture: from the users and CX-perspective in terms of the client’s business model and as a part of the larger digital ecosystem. Usually, a service designer “wears many hats” in a single project. For example, the role of the service designer can lean more toward certain areas of expertise; such as research, business consultancy, user experience, or accessibility; depending on the project phase and needs.
Data Analyst – an expert who collects, analyses, and interprets data sets from various sources to inform clients’ business decisions and improve service performance.
UX/UI Designer – an expert in user experience (incl. usability) and user interface design who creates user-friendly interfaces for digital products. UX/UI designers translate the complexity of technology into an understandable and appealing form by creating layouts that can be developed to be functional and usable products.
Developer – frontend or backend or full-stack, depending on their area of expertise; programs, builds, maintains, and develops software and applications by using various technologies.
Technical Architect – an expert on the overall technical architecture and structure of the service, guides developers, and works closely with service designers and the design team to enable feasible solutions.
Accessibility expert – an expert who ensures that the digital service meets the accessibility standards and consults the developers, designers, and clients concerning the good practices of accessibility.
The development team consists of at least 2-3 experts. Therefore, especially in smaller projects and teams, some experts may be wearing “several hats” at once. External experts might also be invited to consult on various subjects if the situation calls for it, which in turn saturates the colorful bunch of the development team.
The value exchange
Now that we know what players are involved in a project, it is time to take a look at the game plan. In order to represent how the team plays together in action and what value not just the service designer but each member of the team offers to one other, we need to get granular. In the following chapter, we’ll examine the ways how the experts from both the Service provider, Client, and User sides work together. Furthermore, we’ll find out what everybody brings to the table in a service development project by diving into the everyday cooperation and mutual consulting between the various experts.
As it would not be very user-friendly of us to begin listing all the dozens or even hundreds of things each role has to offer (and on the other hand, feel slightly too generic to say that the developer shares their technical expertise and so on); we will instead focus on the more tangible values that are exchanged within the service development project. This will also help to form a more solid image of what service design is in action, a subject that we know sometimes feels a bit confusing to grasp.
Besides the obvious role-related insights shared by the respective consultants, the everyday interactions within a team of experts could include results and information such as:
- organization/ business development strategies depicting what goals need to be achieved and why,
- diverse (user) data validating the hypothesis on what and whose needs/ problems should be met/ solved in order to execute the strategy and achieve the defined business goals,
- technical parameters and realities on what can be done within the given resources,
- the web service’s strategic long-term plan enables the design and development of sustainable solutions for user inclusion in service of providing positive user experiences,
- objectives and key results indicating how the strategy could be carried through in action,
- data-based ideas and designs concepting what the user-friendly solution might be like,
- visual user interface layouts explaining to the client and developers how the solution will look and feel from the user’s point of view,
- technical solutions developed based on the strategy, needs, and visual designs, ready to be accepted by the client, tested by the users, and iterated by the designers and the developers through valid data gathered through web analytics.
Importantly, the end result is born through the mutual trading of all of these values. Neglecting one might risk the overall validity of the final solution.
Bridging the gaps between roles, human and technology
The Service Designer is responsible for guiding the design and development of the service from a holistic, user-friendly, business-strategic, and human-centered point of view. This is translated through delivered value, such as:
- providing the designers with qualitative user data and gently helping the developers to bridge the gap between code and user experience;
- enabling business development by translating the client’s needs into actionable web-service strategies;
- and providing the analysts’ objectives and key results that help them set proper metrics to measure the performance of the solutions.
Let’s have a deeper look at each of the roles and what value they bring to the others and to the project. The values exchanged among different actors in a service development project are listed below. The list is grouped by roles, so you can easily find yourself there and get familiar with what you can provide and what will be expected from you when working on digital project development.
Client – Industry/organizational expertise
Product owners and decision-makers:
- To User: service that enables good CX,
- To Dev: product ownership (incl., e.g., acceptance testing),
- To Service Design: needs, problems, and goals,
- To Analytics: access to available data sources,
- To UI/UX: brand and visual identity.
Service Design expertise
Tour guides and pedagogs in holistic & human-centered digital service development:
- To User: empathy and curiosity toward experiences, diverse user research, and testing,
- To Dev: human needs dictating the requirements, development roadmap (bigger picture),
- To Client: holistic and human-centered guidance in digital ecosystem development and clear CX design,
- To Analytics: objectives and key results, goals for continuous strategic development,
- To UI/UX: qualitative user data and UX & CX goals.
User – Experience expertise
The primary user of the digital solution:
- To Dev: testing+feedback on feature prototypes,
- To Service Design: use-cases, challenges, and motivations,
- To Client: CX + money/time/data (depending on business model),
- To Analytics: user data, allowing cookies,
- To UI/UX: testing visual prototypes+feedback about the UX.
Developer – Technical expertise
Realists and tech wizards bringing the designs to life:
- To Client: developing the solutions,
- To User: feature prototypes and iteration,
- To Service Design: the technical development possibilities/realities of the digital ecosystem,
- To Analytics: features that enable the gathering of valid user data,
- To UI/UX: bringing the designs to life.
Analyst – web analytics expertise
Enabling continuous development through data-informed decision-making:
- To Service Design: user data, co-designing analytics in terms of continuous strategic development,
- To Dev: data about how well the developed solutions perform in reality,
- To Client: data to support decision-making and validate the value created by the solutions,
- To User: ethical and UX-friendly gathering of user data,
- To UI/UX: set parameters for the UI features that enable viable data collection.
UI/UX-designer – Usability and UI-design expertise
Creating the visual foundations for amazing user experiences:
- To Service Design: visual elements available in the user interface,
- To Analytics: designs of features to promote the gathering of valid user data,
- To User: design of the user interface which enables excellent user experience, visual prototypes,
- To Client: usability + accessibility audits, visualization of the designed feature,
- To Dev: visual example and requirements of what the feature should be like from the user’s pov.