Adventures in Web Application Develompent by Phil Duba: CFUnited: Prototyping for Smarties

Popular Entries

Top Commenters

Nathan Mische (12)
CFFusionDev (6)
CFdevfusion (6)
Peter Bell (4)
Sean Corfield (3)
Rey Bango (3)
Terrence Ryan (3)
ah7866 (3)
Scott (2)
Jim Priest (2)

Slideshows

Dresser/Changing Table...
Images related to the lay...
Nursery renovations...
Pool Surprises...

Search

Enter your email address to subscribe to this blog.

RSS

AGGREGATORS

CFUnited: Prototyping for Smarties

Posted On June 25, 2008 10:44 AM By Phil in CFUnited

In the afternoon on Saturday, I attended the Prototyping for Smarties session by Hal Helms and Clark Valberg. Tangent:Prior to their first session, I believe, I was having a discussion with a bunch of people who were trying to figure out what the "Smarties" candy was. I described it as looking like pills, aspirin, others said different kind of pills, but nevertheless, you can find out exactly what they are by going here.End Tangent. Anyways, as has come to be expected, Hal and Clark's presentation didn't disappoint and Ben Nadel played the hyper-worrying/frazzled developer (like nervous guy, Doug, on Scrubs) to a T (almost too good, you might say, :). What also was good, was having attended a number of Hal's sessions over the years, as well as his Fusebox training back in 2001 or 2002 (can't remember), is that he has reevaluated some of his positions on certain topics, like prototyping and the depth needed to move forward on a project (he now advocates the medium fidelity model). Lots of good points came out of the topic and combining it with the Changing the Game presentation, one can definitely begin to see how to approach clients in a different manner. Here are my notes from the presentation:

- prototypes doesn't make a project perfect
- prototyping is not for designers
- purpose of prototype is to capture requirements
- really for software architecture as opposed to UI design, application flow, how system will be used
- best reason to prototype is to get out of the traditional "requirements specification" where a customer signs off
- interesting tidbit - Hal adds two things in his prototype (one of the corners) that states the cost and time to develop if the prototype is frozen at that moment
- 48 hours maximum between reviews of prototype - Hal's business practice
- medium fidelity - not complete prototype or fully functional - captures 50-60% of user experience, most likely throw away afterwards
- high fidelity - more fully functional, 70-80% (my guess based on description)
- highest fidelity - XHTML/CSS/JavaScript (maybe some CF) - has reproducable aspect for final product
- use real data as possible (doesn't recommend lorem ispum text)

Process Step
- discover stakeholders - who is affected and how are they affected by this project
- determine business goal(s) - why is the project being done? why are we building this? - relates to the other topic presented on looking out for best interests for both the customer and yourself
- define use cases - so and so does this, individual transactions that need to occur, task list on index cards
- build the first iteration - don't get caught in committee, build as much as can before showing to client
- solicit feedback - take in everything, may not use it, don't run the software itself, have the "user" of a particular feature to do it
- iterate prototype - don't stop until you get enough, don't be pushed into just coding
- get full prototype approval - "blood on each screen", essentially sign-off on each screen

Common Mistakes
- prototype fidelity problems
- not knowing stakeholders
- not engaging users directly with prototype
- closing on iterations too quickly
- acting like an order taker
- ask deep questions (ask why 5 times - something about Zen)