UX Runway Iteration: Days 1 – 10, post with James Schmittler
If you’ve been following my blog and writings you maybe know a bit about my work with User Experience and what I call the UX Runway – UX working an iteration or two ahead of technology to make designs which technology teams can then develop to. One of my co-workers, James Schmittler (@jamesschmittler) has written a great piece about what actually happens each day of a two-week iteration from the UX perspective during the UX Runway. It gives a great insight into how a typical iteration looks in UX land and some key places where PO and technology integration is needed. It mirrors well with my project management/ScrumMaster perspective on the UX iteration and I’m excited to share it here:
“Time boxing design can be challenging, but it is crucial in an iterative design process. We need to work swiftly to gather information and deliver well though-out designs in a timely manner. Often times, the challenge is not only for the UX team, but also in the understanding of expectations from business, technology, and fellow UX team members.
While working on a project in 2013, we implemented a framework for delivery that not only increased visibility into our process, but also created a steady stream of polished, reviewed, and useful wire frames. Using this framework we were able to get in front of development and stay there, working from technology’s backlog to ensure the features they would start next had full buy in from all members of the development process.
Below is a rough outline for a 10 day iteration cycle using this framework. It is important to note that this should happen at least one iteration in front of development (the UX Runway). You do not want a team developing a feature while the UX team is designing the feature. You want to give the UX team at least an iteration head start, sometimes more when possible. The key to this framework is gathering ALL of the information and delivering a completed wire frame AHEAD of anything being developed. In this way, no one is “in the dark”.
Let’s begin shall we?
Days 1-5 – The design!
In the first few days the information architect returns to their desk to hammer out the details of the design. This is often a collaborative effort between the information architect and their fellow designers. Often times the information architect will seek out cross functional teams (design, tech, CSS, research) for input to verify we are sticking to design standards, maintaining a workable interface, and also just to get another viewpoint or solution. During this time, communication between the UXer and their development team is ongoing via email, phone calls, or meetings. This back in forth is important as it helps to ensure the design is headed in the right direction and no one has a false understanding of the end goal.
Day 5 – The rough draft!
Once the information architect has their initial draft of the design put together, they will meet with the business team to discuss the progress. This is a gut check to ensure there are no disagreements on the direction. The expectation at this point is that there are limited notes and some items may still be a work in progress. This is a good time for the information architect to ask about new ideas that came up in the design process or introduce concepts that are difficult to explain in email or over the phone. This is also a good time to bring in someone from technology to speak to the feasibility of the design. Most importantly, this is the time for feedback. Everyone should leave this meeting with an understanding of “yes, this is what we want to deliver to technology” or “no, there are changes that need to be made”.
Although I say this happens after 5 days, this could really occur at any time throughout the iteration. The midpoint is simply a good time to check and make sure everyone is in agreement. Meetings like this aren’t necessarily formal in setting, though key decision makers should most certainly be present.
Days 5-7 – The final touches!
Any feedback and/or decisions from the business team in the rough draft review are accounted for in the wire frames. The final touches are applied and notes are added where missing in the rough draft. A final draft is sent out to the business team and other UX Team members working on the project. This is the stage where final buy-in is key. The information architect will look to business to review the final changes and give the thumbs up on the designs. This means, if technology had no concerns or questions they could design off the document starting today.
Day 7 – Hand off to tech!
Only 3 days left, time for another wire frame walk-through! This time, with full support from the business team, we walk through the wire frames with the technology teams. Technology will give their feedback on any necessary additions or changes that need to be made as we go through the document. The goal of this walk-though is to get the final round of buy-in. If there were no major concerns, the document is then shared with appropriate members of the team(s) and can be distributed freely.
Day 7-10 – Last chance!
The information architect will make their final updates. Any feedback from previous meetings will be taken into account and the final draft will be posted. While continued support for the feature in question is to be expected, this stage of the design process is completed. Time to start on the next big thing!
One final thought. The schedule is always ready to change. Days expand and contrast depending on the type of feature we’re working on, who is involved, and how soon “now” is. Sometimes things get moved around. However, I feel this highlights a general sense of how we could operate. The important thing is starting each new iteration ready, touch base often, have early buy-in, and finally plan to deliver ahead of schedule (because you never know when those extra 2 days are going to be needed).” -James Schmittler
Thanks again for the great insight, James. I’d like to add one final piece regarding the UX Runway iteration and subsequent ones: I like to build in a ten percent capacity to each iteration for overlap that will more than likely happen. This time helps to account for answering questions and some possible small redesigns that may need to occur as development is started.