Kevin Silver uses Blend as an excuse to mull over the role of prototyping tools in the early design process and its communication to development teams.
It links to
Parti & The Design Sandwich for a way to derive design criteria for a particular project.
Some article higlights:
Sketches and prototypes serve different purposes, even if they are built with the same tools. Take care not to create a prototype while sketching is still needed.
Buxton makes a succinct distinction between sketching and prototyping. Sketches are noncommittal and tentative. They let you suggest, explore, and question. Conversely, prototypes are specific depictions that allow you to describe, refine, and test your design solutions. So, prototypes are refined demonstrations of your design intent.
Design documentation
must tell the complete story. Sketches and prototypes don't do that, but are good starting points.
To create an effective demonstration of your design intent, you must consider your audience. I have no problem showing a hand-drawn, static sketch to a design-savvy crowd, who can easily see and understand the invisible behavior with little explanation. However, I am more inclined to show a digital, dynamic sketch or prototype to a mixed room.
Documentation is needed even if it's an afterthought:
Dave points out that various departments within your organization—like quality assurance, legal, or compliance—might need to be able to review the deliverables you create to understand parts of a product. Dan Brown reminds us that we also have to consider other documentation needs like guidelines, standards, and pattern libraries when creating our final deliverables.
