How to Manage Your Agency’s Mobile App UX in an Agile Environment


More brands and agencies are moving towards Agile as they realize the power, speed and efficiency of this process. But how does a product owner manage UX in an iterative environment where scope isn’t fixed?

In traditional Waterfall methodology, wireframes and comps are created, internally review, edited, reviewed again, presented to the client, feedback collected, edited and presented for approval. Once UX is approved that’s what is built. No changes to creative, layout, user flow or features. All that is GONE in Agile.

With Agile, the creative process is iterative, which is sometime very hard for in-house teams and agencies to absorb. It creates looming questions ‘So when is UX approved?’ How does the Product Owner obtain executive and brand management approval without the full UX and Creative Comps of the past? How does a Product Owner check progress, review previously requested changes and provide new feedback?

Manage Expectations

While the process is iterative, regular review meetings should be scheduled at the beginning of the project. By establishing parameters early, both the Product Owner and the Agency avoid scheduling conflicts and miscommunication pitfalls that can derail the project.

UX/Functional Review

All mobile app stakeholders should attend the UX and Functional Review Meetings. These meeting demonstrate in-app (remember, every sprint should end with tested and complete features) the features and UX implemented in this sprint. This is an excellent opportunity for all stakeholders to determine if the app behaves as they expected it to, and to provide immediate, concrete and interactive feedback to the team for changes, new features or future iterations. Functional Reviews ensure that what’s being designed complies to brand and strategy goals as well as preventing the internal development team from being slowed down by client testing of individual user stories (as in the pre-waterfall method of complete approval prior to development).

All UX/Functional Review Meetings should be scheduled upon kick-off so the maximum number of stakeholders can attend each review.

Guided Tour

If you’re using an offsite agency or an internal app development team you’ll want to display the app review as a guided tour. Here, the team leads should walk the group through a set of features and typical use cases they wish to present for review. The entire presentation should be projected in the meeting room and pushed out to remote partners and stakeholder via Google Hangouts or some other, far less awesome tool like WebEx or GoToMeeting (shudder). I recommend against passing the app around on mobile devices, because that tends to distract attendees from the topic at hand. Make sure this is a highly interactive meeting with plenty of time for questions.

Mobile Screen-Sharing Tools

There is a host of great video sharing tool to choose from. But how do you share your iOS with Android screens?

With iOS it’s easy. On Yosemite or newer connect your iOS device to the Mac with a lightning cable, launch QuickTime “File” -> “New Movie Recording” Then, select the name of your iOS device (mine’s Infiniverse) as your video source, as shown below:


If you are less fortunate and have PC borrow a Mac from your developers (you need a Mac to run xCode).

BBQScreen Remote Control for Android is a great tool because it doesn’t require rooting the device. The steps are a bit more complicated than iOS but still quite easy.

Rather than approving abstract comps and wires for the entire project and struggling to maintain them throughout the project Product Owners now approve and course correct iteratively in a hands-on environment. The bottom line: Agile increases the amount of control and feedback you have over your mobile app’s UX.

You Might Also Like…

The Line Between “What” and “How”

Introduction A pervasive problem in software development is finding the line between what is a sufficiently detailed description of a product requirement and describing the "implementation details" of that requirement. Put simply; it is a problem of finding the line between what and how. A product requirement should contain everything about the "what" (and leave …

The Line Between “What” and “How” Read More »