So I have made my feelings regarding functional specs pretty clear already. It’s clear to me, and a lot of other folks, that prototyping can be a very powerful way to capture requirements. What I have been thinking more about lately is, “What is the best way to do that?”
While there probably is no single right answer to that question, I have been learning a lot so far. Here’s where I’m at.
The design of experiences is sometimes a mystical field of work. There are so many acronyms for similar or overlapping types of work that may affect the user experience: IXD, UXD, IX, IA, IAD, UX, UXR, VD, etc.
No matter what your title happens to be, you are likely to be spending a significant part of your day thinking about how to design experiences that make sense and make people happy.
Recently, I came across a great post over at UIE that covers the difference between designing for experiences and designing for activities…
In the introductory Kanban post, I provided some background on Kanban and in Part 2, I went on to discuss several ways Agile and Kanban have been put into practice together, including examples of some of the several different ‘flavors’ of Kanban being used in software development.
Now I want to discuss some of the key tradeoffs that might occur in using Kanban systems for agile development, leave you with some food for thought and discussion, and provide some resources for digging into the topic further if I’ve stirred your curiosity a bit.