Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
This article was originally posted in 2014 on

In part 1 of this article, I summarized the background and basics of agile user experience (UX). In this follow-up article, I’d like to move away from the theory and tell you more about my practical and personal experiences working with these methods.

With the rise of agile and lean approaches across our industry, UX professionals are more likely than ever to find themselves supporting agile projects. Yet, many of us seem stymied by the challenge of effectively integrating UX within an agile development framework. As did I.

The reasons are multi-faceted, yet easy to trace: While development teams were offered training in lean software development and agile software engineering with scrum methods, UX designers weren’t seen as an integral part of the software development process. The “waterfall” thinking in development teams is still not yet completely eradicated. In this thinking, UX designers do fancy pixel-perfect designs at the beginning of a development project; “throw them over the fence” to the development team, and then hop off to the next project.

In the last team I worked with, we tried to use these methods in our product team as well as our development team. This is what happened.

Our very first step was to form a multi-disciplinary product team. In the first phase of the project, the product team had 4 weeks to do design thinking and user research activities, while the development team was busy with maintenance of existing systems and evaluating technologies for our new product. After these 4 weeks, we had an end-user validated prototype and a minimal viable product (MVP) in place for our first release of the product. Since at SAP we use scrum as an iterative and incremental agile software development framework our development team was already comfortable with this method and had been using it for some time. We therefore started out with a sprint duration of 4 weeks which turned out not to be sufficient for the way we wanted to work. So we shortened it to 2 weeks. Six weeks before the first release, when our team was under heavy time pressure and needed to work very efficiently, we shortened the sprint duration down to 1 week and adjusted our sprint meetings accordingly.

During the development process, I was sitting side-by-side with the developers and assisting them with design iterations in the code on a pixel-perfect level. I was also having discussions with the product team about how to proceed in future sprints and making wireframes for the items we decided on. So, I was at the same time with the development team and ahead of them.

We were lucky enough to have the chance to continuously talk to our end-users every week throughout the entire development process and always had the chance to immediately incorporate their feedback and discover needs.




I worked for over a year with the team and found it very inspiring and educational.


Some of the things I learned:

Difficulties – Cultural changes are initially hard to overcome:

  • UX would love to have way more time for detailed research, iterations and usability testing

  • Product management and development are used to specifications, and some would love to have all screens pixel perfect in advance

  • It was a challenge for everyone when designers had to do both just-in-time work and work for future sprints simultaneously

The scary stuff for the designer:

  • You don’t know what you’ll get in the end

  • It might not be what you set off to build originally

  • Your precious designs are not set in stone; they could get revisited at a later sprint, and maybe discarded completely

  • You have to concede that even though you are the UX expert, you don’t know everything, you will have to keep learning constantly

But finally: the great stuff!

  • You build a product with the “I totally want this” effect

  • Our shared success and great feedback from all stakeholders and customers was a great team building experience

  • Dev, PM, and UX started to mutually understand each other and talk each other’s language

  • Feasibility, viability and desirability of the product were well balanced

  • As a designer, I had much more influence on the outcome of the final product, as I was constantly working with the team

  • I had fun and made new friends!

So, if you want to try agile UX in your project, I suggest you:

  • Make wireframes instead of specifications and start collaborating right away

  • Get business, design and dev around the same table – best in one product team

  • Set the stage for the importance of the UX role with strategy session and design thinking workshops

  • Conduct quick, focused research

  • Get ahead of developers AND stay with them

  • Decide on priorities from day one

  • Talk with end-users throughout the process

  • Don’t guess; instead learn from iterations

  • Make your MVP (Minimal Viable Product), minimal amazing

  • Find the metrics that really matter to you e.g. net promoter score (NPS)

  • Own the process; don’t let it own you!

I really appreciated this way of working and will try my very best to bring agile UX into all future projects I will support. Having made the experiences described above I would always recommend trying this way of working and sharing your experiences with others. Just, as I did.

Do you have any experiences with agile UX, which you would like to share? I would be really happy to hear your thoughts and ideas on this!
Labels in this area