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.

It is encouraging that people find analyzing data so compelling. Visualizations like the ones you can find at Digg labs can whet the appetite of almost anyone. Environments such as Many Eyes allow users to engage more directly in the dialogue of information exploration. Wordle, a tool that enables you to generate your own word clouds makes visual statements on views that go unnoticed.

Creating a Wordle visualization of your resume seems to be something people enjoy. It reflects back the author’s personal language for articulating their experience and qualifications. I wonder how many altered their documents to direct the impressions they were creating.

People seem to enjoy sharing word cloud views of the news and politics. Wordle generates beautiful pictures using word frequency; the more often a word occurs the larger it renders. This means that what you put in directly affects what Wordle can turn out. While it includes the flexibility of lower casing words, removing noise words and interactive editing if you spend any time with Wordle, you will find yourself tweaking your content.

In an attempt to practice my PHP skills, I created a simple utility to help automate some text processing prior to working with Wordle. Think of it as the presoak cycle of the word cloud creation process. While it is humble in its scope and function, it can heighten the impact of your visualization. Check out Wordle Presoak if this is the kind of thing you are in to.

This composition below presents variations using Wordle Presoak on the same text pulled this morning from Reuters, Palin says Obama friendly with terrorists. Notice how you can optionally maintain quotes and have them play with the words, perfect for telling a story.

What are your words saying?

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.

Thoughtful software engineers and architects struggle between two extremes: traditional software development (i.e. often well documented, planned and executed) and agile development (i.e. often sprint driven, iteration focused). Each offers characteristics that drive the decision to select one approach over the other, however we all fail to communicate what we will not be getting because of our reasoning.

Booch has written about accidental architecture where the end product is a result of decisions that make the solution what it is, not what we might have intended it to be or how we would do it if we began again. This is a plague of almost any developer or architect. Given constraints, we create software and solutions and the result may or may not be viable shortly after delivery. Initial constraints may not be real (e.g., performance is more important than end-to-end user experience), and they are surly to change over time (e.g., mobile devices are irrelevant).

A recent article from UXMatters.com explores how UCD and agile might work better together. Clearly, if a small group of developers are to deliver working code in four weeks time, user centered design – all of user experience – will need to be working overtime prior to the start of development. This is counter to the idea that agile development iterates to deliver better software sooner. Waiting to deliver initial prototypes is similar to having a much larger process governing the flow of end-to-end solution development, do not look now, we are back at traditional software development. Cecil makes a point that it is possible to work better, albeit challenging – it takes a better collaboration between UX and development. I believe this is possible, but it actually takes the right attitude to make it work.

These general challenges have me wondering, “What is it that we are trying to achieve with more nimble methods of development?” One reason is that we want to get a preview of the possibilities without actually committing to a long drawn out process. This is critical in an innovation lab where no one is sure if the current prototype is the next big thing or just a nice experiment. Here in rubs the pain of innovation – “When will it be complete now that it is twitching?” The developers are often pleased at this point, bragging all the excitement that can be delivered from a 30 or 60 day development effort and yet the fun has just begun. They embark on the accidental architecture and the tough collaboration of creating a delightful end-to-end user experience under the pressure of delivering final software in another 30 days, after all it is an innovation team and the whole point is to be fast, right?

Everyone is always attempting to create software the right way the first time and that is where expectations are horribly wrong. We make decisions that trade one characteristic for another (e.g. great end-to-end experience for quicker initial deliver) but forget to revisit that executing the solution correctly, in a world-class manner, requires a moment of thoughtfulness to ensure the end solution, without course correction, will actually deliver value to users and the business. “Iterate often” is a good motto. It keeps everyone focused on delivering incrementally with less overall investment. Great user experience naturally causes rework in an iterative environment. The two processes do not align easily and it takes real work to produce stellar experiences. Patience among an entire team, to do the right thing distinguishes good from great. A place to start is remembering why we approached our work the way we have, to communicate it and ensure that it fits with changes in the environment (e.g. shifts in strategy, management or schedule). All too often, the delivery of an exciting technology drives the desire to deliver more maturity, faster and better without the thought that maybe regrouping actually delivers a bit slower, but with greater impact and longevity.