There is a wide perception that Design in general is just making things pretty, choosing colors and pictures. However this mostly describes the activities related to UI and does not take into account UX at all. UI/UX are often compared with an iceberg where UI is on the top including visual design, illustrations, icons, graphics, color etc. However on the bottom of the iceberg there is a whole set of activities which improve the user experience that are vital for the success of any software product. UX includes but is not limited to research, understanding the problem, creating prototypes and wireframes, content strategy, usability testing, user psychology and many more.
So how to implement UI/UX in an Agile way of working? Scrum is an exceptional framework that has proven its value but yet there is little to no guidance on how to specifically involve and include UI/UX in the Scrum guide.
There are two widely used approaches in the industry, both of which have their pros and cons.
UI/UX team functioning as different entity:
Many companies choose not to include the designers as part of the Scrum teams. Instead they have their own stories, sprints and even separate board. They are expected to deliver designs at least one sprint ahead, for multiple scrum teams. It is pretty straight forward from an organizational point of view, but speaking from experience this is not my preferred approach since initial designs rarely stay unchanged. Also there is a gap in the communication and cross-team dependency. In addition with this approach UX may be slightly neglected. Design deliverables are mostly focused on UI since there is not deep project understanding or enough time.
Pros:
- This approach is mostly preferred in organizations with limited design resources. If a designer supports many teams it is not feasible for them to attend all scrum events associated with their respective teams so another way to organize the work is required
- This approach may also be chosen in organizations that are currently doing agile transformation from component to feature teams
Cons:
- Design is not a linear but iterative process. Initial designs are rarely implemented without being altered or changed a few times due to multiple factors such as new requirements or technical feasibility
- This cause delays in the communication between dev team and design team, moving designs back and forth
- Design brainstorming sessions are seldom done together with the Scrum team that is expected to implement the work
- It is hard for the designers to have deep understanding of the product and its features when they are not part of the team and this may result in sloppy design work
Designers as part of the Scrum team
By far this is the model I have found most useful and successful. Here designers are part of the scrum team, attend the scrum events and work collaboratively on the new functionalities.
Pros:
- Designers are part of the team so communication is quick and easy
- Designs are being continuously polished and improved into the process of work without the fear that this will cause significant delays
- Scrum team takes design decisions together considering all perspectives such as technical feasibility, testing and business goals
- Designers are involved with the mission and purpose of the scrum team
- Everything is implemented iteratively and collaboratively. There is a deeper understanding and focus on the product features from the designers which will undoubtedly result in better outcome
Cons:
- The only drawback is that more design capacity may be required since designers should be assigned to teams. If this approach is not implemented properly it may be overwhelming for the designers, resulting in frustration from being pulled in too many directions
If you find this approach beneficial, but still don’t know where to start, here are some practical tips that will be useful:
- Initial designs for a story may be provided upfront but alterations and refinement to the design will be a part of the process of work
- Sprint planning should be done collaboratively with the designers. Treat the UI/UX work (for mockups, wireframes, research) as part of feature stories and use product backlog refinement activities to actually perform the work and attach it to the stories
- Designers are an important part of the backlog refinement session. UI/UX for upcoming stories should be discussed, taking into account all aspects of the work including technical feasibility
- If designers are reluctant to attend long backlog refinement meetings due to the many technical details discussed, start with 20-30 minutes for going through items that require design input so everybody’s time is used wisely
- Designers should be part of the daily scrum so communication with the team is quick and effective
- Brainstorm together ideas for new features prior to Q planning. You will be pleasantly surprised how good will be the outcome of such session when different viewpoints are included (UI/UX, technical, product)
Regardless of the approach that you will choose, don’t underestimate the importance of UI/UX work for your overall project success. Design team functioning as a different entity may not be ideal, but it is acceptable in case you are short on design resources. On the other hand, once you manage to properly engage designers in the Scrum teams, you will unleash their full potential.
Lance Dacy is a Certified Scrum Trainer® who’s passionate about applying Scrum beyond technology to all areas of business and life. If you’d like more education or certifications related to this topic, check out the upcoming class schedule.