Thoughts on fitting UX/UI design in Scrum

PO’s role in Scrum visualised by Henrik Kniberg from Crisp

I’m sharing my ramblings here inspired by participating a Certified Scrum Master course. As a background, I’m a Bioproduct engineer turned into a Service Designer, interested in Agile Methodologies, and applying them in my daily work as well as I can. That makes me a peculiar case of a designer. I’m creative, but I want also boundaries. I like to organise things, make schedules, and stick to them. I have worked as a part of a Scrum team before as a designer only because I asked, what’s my role in Scrum. So I guess, I just wanted to share my learnings on that.

A while ago I entered a project, where they used Scrum. Before that, I had heard about it, but didn’t quite know how it worked in practice. This project I entered had been ongoing for a good while already, and the product was developed in a large corporation.

Finding my way into Scrum team

So, I was at my first Sprint Planning and the team was setting goals and putting stories in to the Sprint Backlog. I saw lots of technical stuff on the board, but no design stories. Since I was included in the planning, I kind of assumed that my presence was needed, but what was my input if there is no design matters at this planning? But I was new, so I figured, maybe this is just a part of my on-boarding process. After the planning though, I went to the Scrum Master and asked, why there wasn’t any design stories on the board? And he was like, well, let’s add them to the board then. And I was like, yay! I heard that Scrum is all about learning and trying things out to find out if they work, so I was happy to see that my suggestion was taken into account.

How did it go in practice?

It took a while to find out the best way to fit design in the Sprints. The design stories were still separate from the development tasks — which is totally fine — but they were acknowledged. And that was kind of the point — to acknowledge design work also, instead of it being invisible, and just something that magically happens in the background. Having a UX designer or design team as a part of the Scrum team prevents also waterfall-like working and hand-me-downs. Instead of doing all of the design work up-front and then just hand out the specs to dev, we had done most of the design work upfront, and went into the process with developers, so they could understand where we were coming from, and we could adjust our designs to respond the reality.

TLC couldn’t have said it better

But — there always is a but (and I cannot lie)

Iterating designs (or the prototype) as the development has already started, includes a lot of pitfalls. When design work is never considered complete, it’s sometimes difficult to communicate to developers when the designed feature is ready to be implemented. After user-testing the prototype, there might occur new insights that changes the current designs. When is the prototype ready enough to be implemented? This can be avoided by agreeing on definition of done on design stories. This is also difficult, because the design is dictated by users, and we are obligated to provide the best possible experience for the users. That requires continuous iteration of the design or as I tend to say here: prototype. When is the prototype user-tested enough? When should it be implemented, and continue testing after the increment is live?


Even though it’s not usual to include UX designer in Scrum team, I felt good to be included. In this particular case I worked about 60% of my time in this team and 40% of my time in another project. I found being included in the team very important, for three reasons: transparency, communication, and learning. I shared my work, I saw what the development was working on, and I took part in all of the Scrum events. I knew what was coming next, what was expected from me, and ask if something I was working on would even be possible to implement. I felt that I was in the team, and that I was in a safe environment where I could easily ask from a developer I was working next to, if my idea was totally cuckoo-nuts. At the same time I could communicate, if something wasn’t working from the user’s perspective. Getting a quick feedback loop ensured that I, as a designer, would work on elements that were feasible, and I could explain the developers the reasons, why something is designed as it was — especially if the feature was something a bit more complex to implement. I also wanted to learn from developers and their ways of working and tools, since they have a lot to give for designers’ ways of working. How to collaborate on a project? How to do version control? How to share assets? There is a great deal we could learn from developers.


As a final statement, these are my personal thoughts and experiences on this matter. My explanations might not be perfect, and I might’ve used wrong terms here and there, but I felt I needed to get this post out there. I also want to hear discussion on this matter and your experiences about being a designer in a Scrum team, or having a designer in your Scrum team. How did it work? If it worked well, why? If badly, why?

And please, comment also the content of my ramblings. If you catch at all what I’m trying to say here, I welcome you to suggest better terms, or ask if you want to understand better something I wrote here. I love to reflect on my work. Well, maybe love is a bit of an overstatement, but I try to embrace it.

This comprehensive article gives a more structured view of what I try to say here, and the terminology is better explained:

Here is another article that well describes different roles UX designers have and how they connect with Scrum team: