Follow Us
While you're here, we invite you to friend, like and follow us:
TandemSeven Blog
TandemSeven Blog
Part 3 Modifying Scrum to Marry UCD and Agile - Modification 3: Just Enough Documentation
As a follow up to our last two posts (Part 1 and Part 2) this post discusses Modification 3: Just Enough Documentation. To be consistent, let's compare another set of best practices between the two processes:
User-Centered Design Best Practice: Document what you want to be built. Building prototypes are great, but it's difficult for developers to look at a prototype and understand the required specifications. And rich, complex interactions require more communication and documentation.
Agile Best Practice: The only valuable documentation is code and everything else is a waste of time. Focus solely on writing code or improving existing code in order to move the project forward.
Modification 3: Just enough documentation
Documentation is created in the form of annotated wireframes and screen specs to provide just enough guidance to developers to build what is needed, highlighting basic business rules and messages.
Sample annotated wireframe:
Why this modification?
Doing the right level of detailed documentation keeps the design and development teams in sync, and prevents guesswork and misinterpretation. People forget and people make mistakes. This modification acts as a great set of checks and balances--the team avoids forgetting important requirements. Additionally, developers can use the documentation as an early warning system to uncover potential issues or roadblocks before coding begins.
Example A travel Web site needs to be designed for faceted search. When users search for hotels, they are given options to filter the search results. For example, the user may filter search results to see 4 and 5 star hotels that are $200-$300 per night. The requirements include changing which details of the hotel are displayed based on the user's interactions with the faceted search. Millions of possible combinations exist.
A meeting is scheduled; the team talks about it; they arrive at a solution; everyone leaves. The designers document the conversation and the decisions in a visually effective way. During this process, the designers may discover combinations where some of the facets don't work well together. The designers end up changing the design of the form to prevent this issue from happening again. Most of the time, it's a lot quicker to create the wireframes for this edge cases than it is to code them.
In conclusion, just enough documentation actually feeds the design process. The documentation acts as mini proof-of-concepts, enabling the team to make adjustment before a lot of time is spent on code.
Watch for "Modification 4: Tactical User Participation" in our next post.
User-Centered Design Best Practice: Document what you want to be built. Building prototypes are great, but it's difficult for developers to look at a prototype and understand the required specifications. And rich, complex interactions require more communication and documentation.
Agile Best Practice: The only valuable documentation is code and everything else is a waste of time. Focus solely on writing code or improving existing code in order to move the project forward.
Modification 3: Just enough documentation
Documentation is created in the form of annotated wireframes and screen specs to provide just enough guidance to developers to build what is needed, highlighting basic business rules and messages.
Sample annotated wireframe:
Why this modification?
Doing the right level of detailed documentation keeps the design and development teams in sync, and prevents guesswork and misinterpretation. People forget and people make mistakes. This modification acts as a great set of checks and balances--the team avoids forgetting important requirements. Additionally, developers can use the documentation as an early warning system to uncover potential issues or roadblocks before coding begins.
Example A travel Web site needs to be designed for faceted search. When users search for hotels, they are given options to filter the search results. For example, the user may filter search results to see 4 and 5 star hotels that are $200-$300 per night. The requirements include changing which details of the hotel are displayed based on the user's interactions with the faceted search. Millions of possible combinations exist.
A meeting is scheduled; the team talks about it; they arrive at a solution; everyone leaves. The designers document the conversation and the decisions in a visually effective way. During this process, the designers may discover combinations where some of the facets don't work well together. The designers end up changing the design of the form to prevent this issue from happening again. Most of the time, it's a lot quicker to create the wireframes for this edge cases than it is to code them.
In conclusion, just enough documentation actually feeds the design process. The documentation acts as mini proof-of-concepts, enabling the team to make adjustment before a lot of time is spent on code.
Watch for "Modification 4: Tactical User Participation" in our next post.
WELCOME TO TANDEMSEVEN'S BLOG
The TandemSeven Blog is a forum for our thought leaders to engage with you. We encourage your feedback, suggestions and questions, so please leave comments to our blog posts. Our team is ready to participate in the conversation.
While you're here, we invite you to friend, like and follow us: