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.

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.

Anyone living a Web 2.0 lifestyle – using applications like Flickr or Technorati – is sure to have seen a tag cloud. Typically tag clouds depict the frequency a tag has been used within a system. The larger the word, the more times that tag has been used. The idea is that tag clouds are a good indicator of community behavior, which is very misleading.

Tag clouds do provide a navigation interface which requires almost zero learning. Relative size seems like a universal concept for importance. Clicking on a tag usually shows a collection of items tagged with that word. The cloud is often contextual to a given page so digging into a collection is as simple as clicking tags in the cloud.

Tag clouds as we know them are actually not very useful. They are, in fact, a tease – so easy to use and communicating just enough to be interesting. The problem is that just because a tag is used in high frequency is not an indicator for what a community finds interesting. It is literally a display of how often a tag is used within a given context. In many cases the word flower is distinguished from flowers, even though they are obviously very similar in spelling and meaning.

A friend and colleague pointed me to a blog posting discussing how clusters were introduced to Flickr – groupings of related tags without the use of a high-level label or facet. If clustering can be done well, it offers a more interesting possibility for tag clouds. Instead of simply reflecting the use of a given tag, tag clouds could display the activity for a given cluster. It might very well be that the community is interested in food, but more people are using the tags “family”, “friends”, and “porn” so, as a user, you would never know. The use of clusters is an opportunity to reveal the higher level topics a community is actively working with. Flickr has chosen not to label their clusters. You can actually explore Tags / clusters / clusters. However, all you are really doing is browsing clusters of tagged images that are also tagged clusters. A less confusing example is exploring Tags / summer / clusters which limits the clustering to all images tagged with summer, which can be seen as a facet – a folk-facet. Certainly the URL convention makes it feel like a facet, but, is it really?

[digression starts]

Taxonomists seem to be fascinated with the emergence of folksonomies, but are quick to remind you that they are very different things. So, a facet that is applied by a user is different that one used by someone versed in the science of classification. Again, at first glance, Flickr appears to be automatically identifying facets, but is really just generating clusters from leftover tags. For example, look for clusters on Bergdorf Goodman and you get items tagged nyc, newyorkcity, newyork, etc. A typical faceted browse might show a breakdown within that category of clothing lines (i.e. mens, womens, childrens etc). Instead you are left with the breakdown of whatever the collection has been tagged. So, while it is possible to select a tag that might be a facet, for Flickr, it is not a facet, it is a tag. However, I would maintain that a user could intend to apply a facet through tagging, but the usefulness of that tag as a facet is lost because the system itself is unaware of the higher level categorization. Additionally, it would require that the tags, if clustered browsing was going to return a faceted collection would need to be limited to those expected from a faceted collection. (i.e. In the case of Bergdorf, mens, womens or childrens) Otherwise, the faceted browsing would be a mess, worse than not having the ability at all, because there would be no science to the tagging.

Taxonomies and formal faceted browsing are different activities from tagging and need separate user experiences. In that last example, it is clear that a user could intend a tag to have a higher level grouping property, but unless the system understands this then it is in fact, just a tag. If categorization was important in Flickr, I would expect a different interface from tagging to facilitate the classification.

I often ask what the difference is between content that is tagged or categorized “dog”. If I were surfing facets I might have different breeds under “dog” and maybe items tagged “dog” without a breed. If I were surfing tags, I would expect all dogs and if interested in a breed, I would enter it as a tag. Combine the two and I might browse a collection by facet, “dog” and then filter by tag, “flatfaced.” Is this any different than compound tagging, where one tag is ANDed to another tag? (i.e. dog AND flatfaced) Is the difference limited to the intention of the user who assigned “dog” as a facet and not as a tag? What happens when a user applies the same word to both the category and tag? Are they plugged into formal classification enough to distinguish the differences in meaning? Should they be? Should they care?

[digression ends]

Someone needs to birth version 2.0 of the tag cloud where the visualization is driven by the clustering of tags and not just the use frequency of a tag. Maybe someone has. I can even imagine layering user activity of browsing tagged items on top of the activity of users tagging. A fabulous side project!

My introduction to Tufte was a gift back in 1999-2000 as we finished up the first version of IBM’s Next Generation Internet site. Mike Nelson, currently the Director of Internet Technology and Strategy, sent the team The Visual Display of Quantitative Information. It was not until recently that I ordered two more Tufte works, The Cognitive Style of PowerPoint and Envisioning Information. James inspired me to revisit these views on effective use of the high-bandwidth visual channel.

I read all the reviews on Amazon.com on The Cognitive Style of PowerPoint before succumbing to the “add to cart” button. I figured for $7, if I learn one thing from the short essay, that it would be worth the purchase of what ended up something anyone who is already aware of the overused boiled down messages, bumper stickers for stupid people and irreverent use of cheap clipart trash knows. The value is in the thorough academic review and argument of what you might understand intuitively. It is either a validation of your current perspective or an enlightening read, because you are one of the world’s PowerPoint sinners.

Creating presentations is a necessary evil. I say evil because if we had enough time and a more literate workforce, we would have conversations and share papers. In fact, anyone who has given any number of presentations will tell you that it is all about the interaction in the room or on the call – otherwise it is just a one-way experience with limited value and increasing boredom. Yet, businesses and authors offer education on how to better deliver messages through presentation packages, regardless of their impact to ideas. There in lies the key to presenting – no amount of visual distraction or simplicity makes up for the lack of quality thinking. Fluff sounds like fluff even if it is animated.

One of my first internships was with VSI Communications Group in South Norwalk, CT an interactive production house (now called Mentor). These guys made their bread and butter on impactful communication presentations that companies were not capable of producing, but were willing to pay for. Every presentation had an art director, artists, content authors, project managers and developers looking to assemble and deliver a final self-running, cross-platform product in Macromedia Director. What made them successful was their ability to mix art, experience design and marketing to deliver a total package. If a handout was needed or a 3D animated exploratory walk through was required, it was all part of what the client was paying for.

I might be particularly sensitive to effective communication through some of my design background or general business knowledge. I have often thought of writing a book on the effective display of software architecture. An area that is often seen as a complicated series of boxes, arrows and notation that no one but the technical folks need to understand. If you have had the pleasure of being shown these types of diagrams, it usually takes at least one person or an additional thousand words of text to understand what is being depicted. I suggest this is an indicator that, regardless of standards we might adopt to represent architecture and software design, we need more focus on making these diagrams effective beyond our narrow target audience. If we can communicate our intentions to those who do not speak our language, then surely we will all understand what we are trying to do even better. There is nothing wrong with domain specific notation, but our impact is limited by our ability to translate it to those who do not understand us. If it takes special acumen to appreciate my message then I am almost literally talking to myself, something I would like to think is a rarity – after all I am not interested in thinking alone.