Mobile App Development

How to Superpower Your Agile Feedback Process

May 22, 2015

  • Nelson Taruc Nelson Taruc

One of the biggest things to look for in a mobile app developer is their ability to truly partner with a client. (Read about other traits to look for here.)

An essential element of partnership is communication. One of the central aspects of developer-client communication is the feedback process. When it comes to designing and developing mobile apps, giving good and effective feedback is overlooked frequently.

We’ve worked to develop Agile feedback best practices. Here are some key topics for clients and developers to consider:

Which Kind of Feedback is Best?

There are many process and communications pros out there, but one of the most prominent in the design and Agile world is designer Adam Connor. Connor has written about what he calls the three types of feedback: Reaction, Direction, and Critique.

Here are examples based on a customer looking at an e-commerce checkout button:

Reaction: “Yuck!” or “Nice!”
Direction: “That button should be green, not black, and made much bigger.”
Critique: “I think that button will make it more difficult for users to check out quickly because it’s not easy to see.”

Connor focuses on critique being the most relevant type of feedback that customers should give developers. It’s important for clients and teammates to identify what the problems are and why they need to be fixed, but warns against telling someone how to fix it. Understanding the full scope of a problem is more valuable than trying to come up with a quick fix based on a gut reaction. This is why Connor encourages people to avoid reaction or direction feedback.

Once the client and developer understand the full scope of a problem, then the developer can most effectively focus and find time to explore the best possible solution.

Agree On A Schedule

Before you start design or development, the client and developer should agree on a schedule built into the Agile sprint flow. Make sure that schedule includes everyone needed—especially the key app users who’ll be providing the most relevant feedback. The client should have enough time to review the app internally and organize the feedback into a critique-style format.

If a customer has challenges in keeping to the feedback schedule (this can happen for many reasons), schedule regular check ins to help with questions and to keep to the sprint schedule.

For specific sprints, developers should try to request specific feedback from customers. For instance, if sprint 1 is focused on building out the navigation flow, the developer should tell the customer to focus on navigation rather than on other parts of the app that may not be complete.

By understanding the three types of feedback and by agreeing to a schedule that works for all involved, it makes it much easier and quicker to go through app review or app demo meetings.

Harmonious Feedback

Developers should resist taking feedback personally or viewing it from an adversarial point of view. This can be difficult, especially if feedback isn’t a well-developed critique. If developers receive reaction-type feedback or something that seems personal, they should pause first. Take a breath. Help to redirect the feedback by asking what the user or target audience would think (in the case the feedback is coming from a non-user or non-target audience). Tease out a better response with phrases like “Tell more more about why you said, ‘Yuck,’” or whatever the feedback was.

The developer and client are on the same team. Whether you’re the client or the developer, everyone is working toward a common goal: making mobile apps and experiences the best they can be. Feedback, when given well and worked through, is never negative. It’s productive.

Why It’s So Important

Time and money are limited resources. For designers and developers, it’s crucial that they process feedback efficiently to make apps better. Setting up expectations, coaching your other team members on feedback quality, establishing a schedule, and focusing on team unity are all important to set the stage for productive Sprints and ultimately great apps.

What have been your experiences with feedback in development and design, positive or negative? If you have any other tips to share, please post them to our comments!