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.
agile dependent teams information architect information architecture iteration plan iteration planning scrum sprint plan User Experience UX Runway
2 Responses
Natalie, interesting article. Certainly a lot more needs to be written on UX in agile – nice to see more on the topic!
I’m wondering a few things. You mentioned “polished” at one point – what are you find as far as trying to balance the design vs. the feasibility of it? Have you run across any of these?
– The wireframe far exceeds that story or feature – and then the customer is disappointed because what they saw and what they get are different. In some cases, the wireframe is not even technically possible given the other items in the backlog. How you you handle those issues? (you mention some of that (Day 7, etc.), but I’d love to hear more details this issue if you have run across it).
– The development team could have built an evolutionary prototype, instead of a throw-away wireframe in the same amount of time.
Those might be blog posts on their own! I’m okay if that is the case… it would be good to hear how or if you have contended with those!
Hi Jake-
Your first question regarding polished and balancing design with feasibility: yes, with every design we make we need to balance these things. This is generally a compromise between many parties including UX, POs, technology and architecture. Many times feasibility issues are identified by architecture and we will redirect our designs. Another solution is when the design is feasible but it will be more effort to implement versus something simpler. In this case we have the design we recommend but will also build out some other choices. The architecture and technology will give estimates of the choices and the PO makes the final decision of what they want based on our recommendation and the money they are willing to spend building it. Another factor is Lean UX and only developing what is needed at the time, very rudimentary wireframes or drawings or something more polished depending on the feature or wireframe.
For the next piece – often the wireframe does not exceed the feature or story. As this is a very collaborative process and many of the teams are involved, scope expectations are set up front. With the estimation I mention above, this helps to keep everyone on the same page for what is being envisioned and what it will cost/how much effort it will take to develop.
Finally, regarding prototyping I’m not certain where you’re going. We do build prototypes for certain things, especially for user research. I would say a prototype may be more throw-away than wireframes in some situations. Regarding that, it all depends on the situation; it’s not always wireframes “or” prototype, some times it may be an “and” while sometimes it could be neither. We take it on a case by case basis based on what the business and development wants, what is feasible based on the timeline, the uses it will have, and what is the most cost efficient if budget is a concern (which it usually is).
I’m certain there will be more posts. Thanks for the feedback and dialogue. I look forward to seeing you at the Scrum Gathering in a few months!