Seven Challenges for Interaction Designers Working in Agile Teams and How to Fix Them

16 Jun 2014

These days we hear a lot about Kanban, Scrum, Extreme Programming and various other Lean development approaches. Among the buzz is a lonely interaction designer who is tasked with creating the best user experience known to man.

In our experience agile methods and interaction design can bring out the parts of each other. The secret lies in setting up some ground rules. Because, let’s face it. Interaction design and agile development have really different approaches to their projects.

Working in agile teams can be challenging because the interaction designer has to keep an eye on the big picture in an environment that loves details. We are really talking about two very different levels of detail. And this is where conflicts can arise.

About the role of an interaction designer

Let’s imagine that you are assembling a puzzle. With smaller puzzles it is easy to gather the pieces and put them together. But if we are talking about a huge information system then things are not so simple anymore. You miss one piece and things can turn sour very quickly.

The interaction designer is challenged with having a good overview which is also the reason why he should talk with other people besides team members and representatives of the client (e.g. product owners).

The designer seldom gets the big picture. Instead he has to operate with a piece of information here and a piece there. Sorry to say, but this makes building a good user experience a pain in the bum.

Errors that creep in due to bad information can be so serious that you have to remake an entire system. This might be ok for the development team, but it is wasted money for the client, plus a highly expensive lesson to boot.

In order to design a good user experience the designer has to know about the business goals of the client, the way users think and also the technical possibilities.

Situations where the interaction designer is just starting with his work and development is finishing up their third sprint is nothing new. Sometimes we even see that the user interface, without any interaction is considered „ready „or „getting ready“.

In order to avoid a situation like this the designer has to work on the project before developers start with development. And now a little more about the challenges that face us.

How much preparation do I need to do before development starts?
The interaction designer is responsible for the big picture. In order to get a better idea he usually kicks things off with user research. At this point he has no idea what the final solution will be like. The business problem alone is not enough.

At this stage you shouldn´t focus too much on the details. You have to be ready to show off your work in progress, ask for feedback and talk to people. The amount of preparation depends on the project and also on what can be done in parallel with development and what can’t.

Often enough you also benefit from including the developers. If they can’t yet start working then they could help in considering the pros and cons of various approaches.

Developers are not usually happy when the designer does interviews and collects information instead of spending all of his time drawing wireframes. This is where it gets challenging. How much should you risk with everything going to shite and it turns out that you have built the whole solution incorrectly or run out of time?
How many team members should you include in the design process?
In a perfect world you have teams collaborating on both research and discussions. In reality you are faced with the fact that people rarely have enough time to meetup with you and discuss possible solutions.

The more you include other team members to these sessions the higher the probability that you will not have to fight over every tiny detail. There will also be less changes in the future and you have the best possible solution in the limits of the project.

Give people a good reason to take part of the discussions and take in consideration that their time is limited. The current best practice is to agree on a regular time every day.
How much documentation is needed?
The effectiveness of agile development lies in as little documentation as possible. The content of agile documentations depends heavily on the requirements of the team and the business side (in the development phase).

Other important things to think about are development cycles, what happens to the system afterwards, and how detailed the prototype needs to be in order the others understand it and remember the results of user interviews 2 months from now.

A good way to document is to create them as visual as possible. You can also insert comments into the prototype. It is also a good idea to present the result yourself and not to send them around via e-mail or Skype.

Feedback is best collected from discussions and not e-mail. This is more effective for all parties. One of the roles of an interaction designer is to mediate various parties via translating thoughts and ideas.
How much can be changed?
Making changes while keeping an eye on the big picture is extremely hard. You often hear about how they both are required, but it is very difficult to do them at the same time.

The Interaction designer has to choose where the line is drawn, which details can and which shouldn´t change, i.e. which changes will essentially begin to ruin user experience.

A good practice is to first keep the user workflows as a storyboard and try out the changes there. Changing the navigation scheme is generally not a good idea.

You can do this only when you have a good reason for it. If there are any doubts about the navigation scheme then we suggest doing some quick RITE (rapid iterative) tests. They are quick to do and will let you know if the general direction is correct or not.

Other times it is better to agree on some user tests than argue hours upon hours over forms. One user test can take 15 minutes and you will see if it works or not. There is no point in speculating and arguing.
When is „ready „actually ready?
Is there a criteria for it? When is the functionality good enough to show to a client? With agile teams we have noticed that development is a lot faster when visual design is out of the equation.

This is why it is reasonable to develop the system without red or green buttons. At one point you have to draw a line where the main work is done only finer touches are left.

Due to the number of iterations that comes from the development speed you have to see that the overall structure is in place right at the beginning. You can always make smaller changes. It is important to realize that the criteria for „done „change when visuals are adjusted.
Involving other departments and end users in the process.

You have to talk to a lot of people in order to get a good overview. In agile development this is generally frowned upon because developers are constantly lacking in the time department. But the role of the interaction designer is to fuel discussions and find possible solutions through them.

We recommend taking the product manager and having at least two half-hour meetings with him per week. Because the product manager is always busy, you have to find other people who can give you the required information.

It is very important to ask for the product manager`s blessing because this is what saves you from the conflict that might arise later on.

The product manager is not always enough. It is very easy to talk with one person, but the organisation is not comprised of just one key person alone. You have to talk with as many people (affected by the system) as possible.
How much is enough?
In other words, how long is the user interface tuned and how perfect should it be. The easy answer is that there is no straight answer. Sometimes it happens that in the course of a long a process you get a form with only a single field. Other times the designer has to let a non-ideal version go into production.

In the end it all comes down to good communication

Development and interaction design can work together without any hiccups. They have to see the content of their work and how it differs. Meaning that designers have to understand the developers and vice versa. Good project supervision is equally important.

Good user experience is born when all parties put effort into it. You can`t isolate development and design. The more people you have in the process the better the end result will become.

The interaction designer has to be flexible, cooperative and ready to bend business requirements if needed. Not all are happy with the latter, but most of the time they calm down when they see how it affects their development budget.

Share your experiences!

Got an interesting story to tell? It doesn`t matter if it was positive or negative, all comments are warmly welcome in our comment section below!

If you have any questions or if you want to know more about interaction and user experience design then write to us at trinidad@trinidad.ee.

Other popular articles