Prototyping is something software builders leave to user experience professionals and that is completely insane. Prototyping should inhabit everyoneâ€™s being. It is an opportunity at any step of any process or creation. There are too many first drafts called final drafts, especially in software.
Regardless of your software development methodology, agile or waterfall, there is always a notation that says, “Take time to prototype.” Practitioners speed by this phase as if it were distracting from the final form. Project leaders receive pressures to deliver more, in less time and at or under budget. Where in that formula is prototyping placed at the top?
Some companies handle this by creating smaller development teams, housed in research and development or branded agile extensions of the larger delivery organization. This is where people think the prototypes come from. Does location, context or reporting structure have any bearing on how real software is?
noun, verb -typed, -typâ‹…ing. â€“noun
- the original or model on which something is based or formed.
- someone or something that serves to illustrate the typical qualities of a class; model; exemplar: She is the prototype of a student activist.
1595â€“1605; < NL prÅtotypon < Gk prÅtÃ³typon, n. use of neut. of prÅtÃ³typos original.
When I joined a skunk works team at IBM directly from college, everyone said they created prototypes. These prototypes were designed and delivered to scale to the entire enterprise. People called them prototypes to set expectations and help the traditional brass understand why a one-year project might be delivered in three months. Rarely was there anything approximating a prototype â€“ well maybe the very first version.
There have been notable individuals that would have the courage to rewrite what they had coded to achieve greater aesthetic or optimal execution. It is a humbling, empowering and inspiring experience to throw out your current work in attempt to write it again better than before. This is the closest I have seen to developers creating prototypes and this is a rare occasion because we so easily rationalize how there is so little time, so little money and so much more to do.
First drafts make lame software, hence we iterate in hopes to accelerate the separation of curds and whey. In the end, this is not prototyping. Prototypes offer the opportunity to understand what is uniquely delivered by the solution, what is important to end-users and how the way the solution is built helps or hurts those two points. This is why the process often ends up being a user experience deliverable. The challenge and thus opportunity, is that maybe what is deemed important is unfounded. Maybe the feedback users provide is based on a poor articulation or misguided offering.
Prototyping in software development educates the architects, the developers and, in turn, the user experience professionals. By building relatively low investment prototypes through rapid development tooling, the notion of throwing the resulting build away seems palatable. It offers the opportunity to learn without entering the software delivery cycle â€“ skipping the prototype is the quickest way not to have freedom to try things. Once there is focus on solution delivery, everyone creates a context that prevents the exploration of what is right. Everyone is left to struggle with making what gets delivers as good as it can be, given the circumstances.
This is all likely generalizable to many professions. Creative types work through revisions as part of their craft. Prototypes educate you, your team and others to the importance of the end direction. It forces everyone to approach the real work with purpose and limits the exposure to making poor decisions under pressure or pretense. Spending the time up front pays everyone back during and after delivery and yet it is not prioritized as such. Instead, we hope that professionals executing a good enough approach will deliver something remarkable.