You will need some format to process your thoughts to get things going. Many times (some of) that stuff gets in to the communication documents. I was in a project that had a leader who wanted to cut out **all** the waste. That included all stuff that looked too much like something presented in a formal waterfall documentation. And it did not work out.

It’s one of the major challenges of UX as a professional field to pull people out of those outdated mindsets.

That said, it just so happens that I wrote a book on Agile UX, design & development (for which, btw, also the big kahuna Jeroen van Geel has written a very nice chapter.
It will be published late summer.

I’ll paste in a shortened fragment on documentation, that gives our nuanced view on documentation in Agile UX, more specifically Scrum:

“Eliminate waste” is the first principle of Lean software development, and Scrum has borrowed many of its principles. But is documentation “waste”? Sometimes it is, but not always. Ask yourself what the purpose of the documentation is, and take a different approach to each type:
1. Documentation used to establish project preparation, such as program of requirements, negotiated business rules, sitemap. You must be very careful with these documents. They are typical waterfall documents. A sitemap is only useful if you’re prepared to adjust it as more insight is gained.
2. Documentation used to guide design & development on a continuous basis, such as brand values, user insights, a product statement, coding guidelines-—this is what you need. Use PowerPoint style not reams of text, so it can be displayed on the wall and seen from a distance. Remember, nobody will look at documentation that’s put into a folder on a server. Waste of energy!
3. Documentation used to transfer knowledge among various disciplines-—flows, wireframes, and PoRs-—are rarely needed when team members work together in the same room. Usually a simple sketch or a quick one on one is all it takes to run through a story. We believe that only very complex functions or interactions need to be specified and worked out on a computer.
4. Documentation for comprehending the project at a later stage—such as an editorial guide for when the project has gone live, a corporate identity manual, description of important technical preferences. This kind of documentation is essential. It is an intrinsic part of your product. Provide something tangible—not just an email with attachments.

– I’d be happy to hear your thoughts!
Pieter

We don’t have all of our patterns defined yet. So I am integrating the visual style into our Axure widget library. onHover of a secret hotspot in the top right of each widget, I popup the visual of that widget and the corresponding CSS. My Axure widget is styled as close to the visual as possible, but it ain’t Photoshop (or FW) so I feel that this is necessary. Thoughts?

Also, you said that “….Our QA team bases their tests on mocks, prototypes and a shared understanding of how the system is supposed to function. This is built through collaborative problem solving with te whole team…..”

Can you elaborate a little bit on this? What sort of mocks are you referring to? Do they exist in addition to the prototype? are they hi-fi? lo-fi? quasi-medium-fi? We don’t have a visual designer, so I struggle with how to ensure screens are built as designed. One thought is to integrate QA into your collaborative sessions every few days in a two-week sprint.

Great article man. I will keep fighting the good fight over here now that I have a sense of hope!

A new valuable web page that I have visited! A lot of wonderful info here…