…was an argument that a colleague of mine started when we were discussing the Agile ways of working and roles of designers in this realm. And indeed, Scrum (the most frequently used of lightweight software development methods), has this in the guide:
“Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule. Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.”
Since the official guide does not differentiate the roles in a development team, such as the business analysts, UX and/or UI designers, quality assurance testers, and so on, how do we accommodate the process towards their intricacies? What if the designers’ way of working is different from the “typical” members of a development team, for example the software coders. So, in highly coder-focussed agile methodologies such as Scrum, how do we define the role and process for the designer to successfully deliver a product? And a user-centered product at that?
MOBGEN, like the majority of advanced IT organisations, uses Agile methodologies to organise workflow and process in most of our projects. We work with various clients who come from all walks of life, with different company sizes, cultures, ways of working, expectations, and many other differing factors. And due to this, we’ve realised over the years how crucial it is to build specific teams that will be compatible with each project. Collaboration is such an essential part of the Agile development, and knowing who (and how many) to assign to a project team to achieve great results can make or break the game. And for me as a UXer (user experience researcher and designer), it is especially interesting how this resource allocation works in terms of designers.
The term ‘UX designer’ is a broad one, as there are so many profiles (or archetypes) a designer can have. We also found that certain projects had specific UX designer + UI designer combinations. Where one project had a team with one UX designer working harmoniously with two UI designers, another team had UI designers doing some occasional UX tasks. Then we were curious: apart from the experience of the creative director who assigned these resources, is there a way to define which UX/UI profiles fit which kind of project?
This started an internal discussion within a small group of MOBGEN designers. At one point, we realised that our opinions were one-sided as we were basing them on our own experiences which shared many common familiarities.
So we decided to take this further than MOBGEN – as part of the Amsterdam UX community, we organised a roundtable discussion at MOBGEN. There were ten external participants: eight UXers, one product owner and one innovation engineer.
As an exercise, we collected the roles and responsibilities that UXers have in their projects. We focussed mainly on tasks that are expected of a UXer.
These are the ones that we came up with during our session:
UX roles and responsibilities
UX roles and responsibilities grouped
As another exercise, we defined the different processes that we’ve observed in the workplace. The list came from our own experiences working on different projects and industries. The following are the descriptions of each process that we’ve defined, along with for which projects they are best fitted to.
- The loop
What we called “The loop” is a process where the roles in the project team work parallel to each other: the business analyst (or product owners) defines the requirements; the designer creates the wireframe or designs; the dev implements the functionalities, and so on.
We concluded that this model works for the development of completely new products, where the team needs to build quickly, and if necessary, fail quickly but learn fast to achieve the end result. The model is also assumed to work best for small scale projects.
- The Waterscrumfall
What we called a “Waterscrumfall” model, is an iteration of different tasks being performed in different dimensions. First, the Business analyst team comes up with the business requirements. There is an overlapping period when BAs discuss the business requirements together with the Ready team so that they can develop wireframes and designs based on the requirements. Then, the Ready team creates the wireframes and designs that need to be approved by the BAs to ensure that all requirements are fulfilled. Finally, the designs are delivered to the software development team who will implement the designs.
The disadvantages of this process are that:
- the designers have no input in the business requirements
- the “Ready team” may feel pressured if the business requirements aren’t refined enough to be turned into wireframes or designs, while the development is pressing them for new designs to be developed
Based on the experiences of the participants, we concluded that this model is a good fit for:
- multiple scrum teams working on the same product
- corporate beasts
- medical, finance, airlines industries
- the transition phase from waterfall to scrum.
- The Spotify model
Some of the participants have used the Spotify model of scaling while working Agile. The model incorporates a cross-discipline nature where “roles” take over “people”.
We’ve concluded that the Spotify model would work for
- large projects that employ large usability testing capabilities
- strategy-oriented projects
- “Design sprint”-like process
This process involves the development and design teams working together to create ideas in the form of wireframes. Afterwards, while refining and pixel-perfecting the designs, the development team can start working on implementing the functionalities based on the wireframes.
“Design sprint”-like model
One advantage that was pointed out during the session is that this model serves the project very well in terms of communication.
- Sprint 0
“Sprint 0″ is an add-on to the initial Agile (particularly Scrum) methodologies where the role of design was heavily underrepresented. The idea is that designers should work a sprint ahead to prepare the work that will be developed by the dev team in the next sprint.
This model is also characteristic to contractors (or agencies) who are hired for producing designs only without having to collaborate with the development team during the implementation.
The combination of “The loop” and “Sprint 0” can work well together for small MVPs.
In conclusion, to refer back to the title of this blogpost, there is a role for a designer in Agile processes, and this role is always evolving. The expectations of a UX designer’s participation changes along with advancements in UI tech and design tools, and general market awareness of the role. As we observed during this round-table session, in practice, no one single methodology fits perfectly right to a project, and as UXers, it is part of our responsibility to continuously keep improving our tools, methodologies and practices in order to achieve greater results in collaborations. UXers all over take inspiration from other companies who got it right, then mix and match ideas and tools to get what works best for them. When one single process is not working for the team , a combination might. However, when no improved methodology or process is working, it is recommended to change the culture.
As Christian Beck puts it, “There are different skills within the field of UX design, each which lend themselves to different roles, which are then suited towards different types of companies”. We, as a part of the UX community, are yet to define which UX roles are best fit for which types of teams or organisation.” This round-table was trying to do exactly that: assemble the UX community to start a discussion on how UX roles fit in Agile processes. This “work-in-progress” is still open for questions, challenges and debates — that we hope to achieve by getting the subject out in the community. If you have any suggestions or remarks, please do let us know 🙂