motherfothergill's pixel imperfect design

UX and visual design within a scrum environment can present some real challenges. In order to keep design from becoming the bottleneck it needs to be done a sprint or more ahead of the  implementation sprint. This is especially true for the MashedIn team that I am currently a part of where sprints are just 1 week in length. Design also needs to be forward thinking and tightly coupled with business strategies to avoid throwaway work. How can this be accomplished while avoiding the well documented pitfalls of waterfall or scrummerfall and achieve the benefits agile offers? The developers on the MashedIn team are a pretty smart group and it would just be stupidity not to involve everyone in design even though implementation may be their primary focus. Introducing the team to designs during planning at the beginning of a sprint and then simply implementing these designs does not seem like a viable option.  This approach yields lower quality due to rushed decisions based upon little or no user data, design by committee, and poor task estimation. It also drags out planning and actually reduces overall velocity. How can design for later sprints be performed within the team while maintaining velocity on implementation tasks? Team involvement in UX design clearly does remove some focus from the implementation tasks at hand but over several sprints it should actually increase efficiency. Part of the reason being it keeps everyone up to date and on the same page thus sprint planning requires far less communication and decision making.  This approach provides  the UX specialists and BA’s the time required to perform necessary research and analysis. It provides time within each sprint to communicate the findings of user research to the team. By keeping everyone in the loop, and involved, higher quality decisions can be reached at every level for every task and the duration of sprint planning is reduced significantly.

In this post I will outline some of our recent changes to the design process of MashedIn.

During the current sprint we start by brainstorming ideas for a feature that is 1 or more sprints in the future. In this example it is the introduction of recommendations to the MashedIn widget. After a short brainstorming session all the ideas are considered and wireframes or some testable artifact are produced for 1 or more approaches to the UX. This is about half a day of work for 1 person.

In the case of recommendations I produced wireframes then presented them to the team in order to ensure acceptance criteria was met.

Next the wireframes were converted into a working prototype that could be properly user tested. This was about half a day of effort.

Prototype V1

This prototype was then tested on usertesting.com. User testing this feature presented a unique challenge because it is all about mutual connections and how these can provide value when making a purchasing decision. The user could not actually login to see themselves or their actual connections. We tried to remedy this by using sesame street characters that would represent the user and their connections.

The user test scenario was as follows:

“You are the Cookie Monster and today you want to break out of your comfort zone so you have decided to try cheese for the first time.

You have found a listing in the yellow pages for the bulk cheese warehouse. On this listing there is an area where you can see how you are connected to bulk cheese warehouse and recommendations.”

User 1 –  Test Video

Findings from the user tests were then documented and “demo-ed” to the team. At this point some technical considerations were discussed allowing us to avoid complexity and 1 missing acceptance criteria was uncovered. Using the feedback the prototype was iterated over.  This was about a half day of work.

Prototype V2

The MashedIn team is currently implementing this design.