Spirited Thought

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?

pro⋅to⋅type [proh-tuh-tahyp]
noun, verb -typed, -typ⋅ing. –noun

1. the original or model on which something is based or formed.
2. 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.

Mark Detweiler from SAP has an exciting article – Managing UCD within Agile Projects – in the May / June issue of interactions. Last year I used SCRUM to manage a small development team on a high-profile project and one of the lessons we learned was that agile development does not work well with disciplines that are not also agile. The development is managed and completed in a series of sprints (we worked three, 30 day sprints) and the application was twitching before any formal UCD work had completed. This challenge applies to more than just User Centered Design (UCD); accelerating development is only so valuable. Detweiler’s UCD centric view offers a series of tips on making a better go at it, but the truth is this problem needs a more radical conception.

Detweiler offers three iterative UCD phases, Understanding Users, Defining Interaction and Designing the user interface. One observation is that UCD teams need to focus their energy on work that influences the current development sprint. Every profession has more they want to do. Delivering it apart form the product development positions their brilliance it to be ignored.

Understanding users is important, but it is not going to hold up development, so what is the minimal amount of work that needs to occur in order to have the development team be more considerate of the user context. Since we are iterating, maybe each sprint has a refinement of the user definition. One thing for sure, the developers will create a user persona if one is not provided.

Defining user interaction has to happen in a more collaborative manner with the development team. It is often just as easy to code the application, as it is to write the use case documentation. This does not mean use cases are a waste of time, but we need to ask what about the document is going to influence development. The time may be better spent with the UCD professional in the initial task breakdown meetings to help define interactions in detail. Having access to a UCD professional as the development occurs helps accelerate decision-making, but the goal is not to have the solution be perfect – it is to have a thoughtful solution, where lessons learned inform the next sprint’s interaction design. The UCD professional needs to own their role representing their stakeholders, but not constantly checking in to see if they are meeting expectations – there is simply no time for checking in and reporting back at every turn.

Designing the user interface as part of an agile development project is difficult. Short of starting this work prior to development, we need to find the opportunity in having the user interface be quick and dirty. An existing design system can address the developer’s need to assemble the application without having to worry about the overall application style. Assuming that a custom user interface is required, the designers need to be in the boat of iterative design. Save the Mona Lisa for a few iterations from now. If you want to influence this sprint’s user interface, worry less about the pixels and more about the styles. Design elements that telegraph where the design will be going. Development is iterative – it is assumed things will change so influence at each point, but save the masterful work for a time when it is not needed yesterday. Great work often takes time; why pretend it can be done in less?

All of this feels a little sloppy and this is why I think what we need is to revisit UCD and maybe the larger thought of user experience and how it is most affective in an agile development environment. This issue is exacerbated in innovation teams where often prototypes catch like wildfire and suddenly a solution with little to no formal UCD thought is at Version 1.0, causing pause to the value and role of UCD. We need to do more than apply more resource or slow down development to accommodate external dependencies. We need to do more than just the same thing in a slightly modified way. To be successful, we need to reinvent UCD or stop being agile.