How do you follow-up UX-suggestions during a project?



I’m just done studying a master in interaction design, and have started working. In my company I’m the only interaction designer, and there is no dedicated designers. The company work agile, and use mostly scrum-ish methods. So I’m involved in a lot of projects, and are having a lot of fun.

But my struggle so far is

  • How do I make sure that my suggestions for UX-improvement are followed-up during the project? I might not be working on this project at the time when the suggestion is needed.
  • Do you have any good tips/tools how to “store” overall ideas that need to be checked into during the project? (For those of you who use TFS or other backlog-tools, do you make your own design PBI?)


Hi Ingeborg!

Do you have a project manager or scrum master you can chat with to make sure your UX workflow ties in properly with their Agile approach?

Having a Kanban board up somewhere public might help keep track of the status of UX suggestions, and help ‘store’ the recorded information. And making sure the user feedback is included where the team decides whether an issue has been fully addressed yet.

The most important thing is to not get bogged down in documentation when trying to communicate with others in your team. Keep it light and on-topic - sketches and chats work well for this. Work with people where you can add value and insights to their work, and try and give them quick, useful feedback without telling them how to do their job. This will hopefully also help evangelise the user-centred design approach, and help you make allies so that it’s the team who end up carrying the responsibility for UX, not just you on your own.

You do need to work out-of-sync with the rest of the dev team. The usual ways this might work for 1 week sprints is to be researching and outlining things the the week before the development sprint, and then testing and suggesting with feedback the week after. Does that sound like it would work where you are?

I know it can be overwhelming working as the sole interaction designer on multiple projects at once! Been there. =)

Make sure you’ve had a read of Jeff Gothelf’s guest blog post on this topic:


This might be a handy article too, Ingeborg. It’s not about Agile, but is a good take on how to preserve and combine UX insights with production work. It’s written by Aarron Walter, Director of UX at MailChimp:


Thanks for very helpful answers and articles Luckha

We usually have a scrum master and a product owner, but they are not used to work with designers. So I guess they have to learn how to include my work within their workflow as well. So it is here I need to find out how that best can be done, and figure out what works best for both them and me.

We usually don’t use Kanban-boards, but we have a digital function to make one that is accessible for everyone. So thanks, I’ll check if that might be an useful tool.

The plan is that I’m going to work out-of-sync with the dev-team, although we have longer sprints. But we are not there yet… Although our dedicated testers are good at giving feedback on UX-matters in things that are developed. So I guess the most important thing is to be ahead with research, outline and sketches. A process I think is good to do togheter with the product owner.

So I guess the key-points for me are

  • Make sure the product owner/scrum master know how to include my work in the process
  • Check into use of Kanban-boards
  • Don’t drown in documentation
  • Keep on working for coming out-of-sync with dev-team


It sounds like you’re on the right path, Ingeborg. =) The product owner and scrum master should absolutely be including your work! I’m a little bit wary when you say ‘dedicated testers’ though - do you mean you have people acting as surrogate users?

I’ve had plans to write up a blog post on exactly this topic (a [B]101 for integrating UX with Agile[/B]) for a while. I managed to dig out some of my notes that I’m hoping to expand on when I do eventually get around to it, but here is a summary of 7 key principles that you might find useful: [LIST=1]
[][B]Get contextual feedback from real users[/B] is important. Surrogate users have some drawbacks, and marketing methods (surveys, focus groups) don’t provide enough of the user behaviour to be truly useful.
][B]Using a ‘Phase 0’ to define system scope and structure[/B] helps with problems that can’t be solved by iterating.
[][B]Design work is done one iteration ahead[/B] to give the UXer a head start on component design, and [B]testing is done one iteration behind[/B] to give proper attention to feedback that is otherwise under pressure from the same sprint time restrictions.
][B]A UX stream can run in parallel but separate[/B] to the agile development stream, so that a wider focus on big picture consistency isn’t lost.
[]If there isn’t a separate UX stream, then a ‘[B]designer’s holiday[/B]’ (like the ‘programmer’s holiday’ concept) can be the opportunity to step back and look at the overall coherence of the design.
][B]Spikes (or Architectural Spikes) can be used to address key design problems too[/B], and the whole team can be involved (the risks are otherwise the whole teams problem too)
[*][B]UX is a full team member[/B], in order to maintain the cohesive, cooperative, co-located priorities of Agile teams. However, it’s a reality that some UXers will need to juggle multiple teams.
[/LIST] These principles come mainly from Hugh Beyer (twitter: @hughrbeyer), my go-to person when I want to learn more about User Centred Agile Methods. Here’s a good interview with him by UIE: and if you want more concise and practical tips, you can also check out his short 60-page book/lecture ($30):


No, with dedicated testers I only mean “functional testers”, that makes sure the product works. And usually they have also given feedback about the UX.

And thanks again, Lukcha for useful resources. I’ve learned a bit about how to combine UX and Agile at the University. And now I’ve gotten some time to figure out some suggestions about how to best include design in agile processes here at my job.