Coopers vision of agile

Alan Coopers view of Agile by Alan Cooper on July 31, 2009

"Lots of ivory tower software experts cheerfully follow their own muse, but in the world of business, the dreams of money-makers are usually in conflict with the dreams of geeks.

In the business world, software developers have always been the whipping boy. In commerce, the delivered-software never matched the envisioned-software, and the technologists got the blame. Executives have always been unhappy about their inability to effectively direct and exploit software development. The only tool that seemed to get results for managers was to keep programmers on a ridiculously short leash by allocating resources in tiny increments. The results weren’t good, but they tended to prevent colossal disasters, which was, apparently, good enough for business.

Over many years, in self defense, programmers increasingly hunkered down to protect themselves. They aggressively lowered the expectations of their managers. They tried to commit to the least possible performance to avoid blame. All they really accomplished was to avoid good performance.

Nobody was really very happy with that situation, but it was good enough to provide most programmers with a decent living and some self-respect.

But many programmers are more ambitious than that, and most of them are used to higher levels of achievement than just “good enough”. All of that mediocrity has generated a lot of frustration for many programmers. Extreme programming was one method whereby developers could force business people to view the consequences of their decisions.

Extreme programming showed developers that there was power in self-determination, and in reaction to all that old defensive stuff, many programmers have finally said “Enough is enough”. They emerged from their bunkers to become proactive in *guiding* the development process rather than just doing what they were told (and then getting blamed for the failure that results). And agile is the mechanism they used.

I’ve long been an advocate of such technological-craftsman-self-determination. It’s just that I advocated it via the “interaction design” point of view. Therefore, agilists and I are on the exact same wavelength.

Now, there are some agile programmers who think that they are dealing with *technical* issues rather than social ones. If you ask me (no one ever seems to actually ask me), these people are trying to take TWO steps backward: they don’t want to return to the hunker-down phase, so they want to reinstate its ivory tower antecedent, that small-world-coding-happy-place that existed before software went big time. That place has never existed in the commercial world.

To my mind, agile means taking responsibility for making a good product. Even if you used test-driven-development, pair-programming, retrospectives, stand-ups and all of the detritus of “agile” but then built a product that nobody liked or wanted, then it wasn’t agile.

One of the responsibilities of software development is to assure that the right product is being created, and then to create it in the right way. The only way to accomplish this is to apply the best practices of programming, design, and all of the other associated disciplines and crafts. *TRUE* agile means integrating these crafts into a joyful, unified, productive whole."

Values in Software Design Practice

A really useful post from Autodesek on the values required for software design practice, this I feel links in with the values outlined out in the IE.

Values in Software Design Practice

by John Schrag on July 10, 2009

Every user experience (UX) designer who practices in a corporate setting knows the breathless whirlwind that is modern business. We designers manage relationships with developers, business managers, and customers, and still have a full-time production role researching, designing and validating features and interactions. We rarely have enough time to do everything we should, and therefore have to carefully choose where to spend our time and resources. Some designers don't even have the luxury of such choice, and instead are tasked with specific deliverables, which are sometimes not the best use of their time. In the face of this industry-wide problem, it's no surprise that dysfunctional design practices can arise and even become so common that they are seen as normal, or at least inevitable. But I don't believe they are.

In 2001, a group of software developers, development managers, and consultants created the Agile Manifesto, a document that outlined a set of simple values that they believed were the foundation of good development practices. What is interesting about this document is that it makes no reference to specific practices or buzzwords -- instead, it outlines principles and values against which any particular practice can be evaluated.

In the same spirit, my co-workers and I spent several hours considering the question of UX design practice. We weren't considering the question of what makes good design; there are innumerable books on that topic. We were considering the question of what separates a healthy, effective design practice from the horror stories we hear about when talking to others in the industry. We came up with two lists; the first list (below) talks about doing certain actions in the right order. Reading the list, these orderings may sound obvious, but they are by no means standard practice:

Setting Goals before Taking Action
Understand Problems before Generating Solutions
Designing before Writing Design Documents
Validating Designs before Investing in Code
Steak before Sizzle

The second list is one of relative values. While all of the items on both sides of this list have value, we value the items on the left more than the items on the right:

We Value:

Validated Data over Expert Opinion
Quality of Data over Ease of Data Collection
Complete Workflows over Long Feature Lists
Achieving Results over Writing Reports
Collaborative Design over Design by Referendum or Design by Fiat
Ease of Use over Ease of Coding
Well-designed Critical and Common Workflows over Complete Coverage of Every Possible Workflow

Of course, a few words in a list doesn't capture these ideas all that well. In future blog posts, I'm going to talk about each of these items in more depth, show examples and talk about what can be done to keep your design practice healthy, even in the face of the whirlwind.

More maps

Another really intersting map visulisation from Pasta & Vinegar

About digital and paper maps

Mapping is a favorite topic of mine, not only because I worked on locative media, but also because I find they are fascinating objects. Maps are really interesting these days as they exemplify one of the design trend I spotted recently: the transformation of non-digital objects by design techniques coming from the digital world. To some extent, lots of artifacts from the material world can be re-designed by applying insights learned when creating weird interfaces and new sorts of interactions.

This is what happens currently with paper-maps which design is reshuffled by people who grew up with video-games and on-line mapping tools, or by designers who consciously want to apply techniques coming from the digital. What is highly captivating in this context is that it also reshapes the user experience of the object at hands. Maps are a good example of such phenomena.

One of the most advanced project along these lines is certainly Jack Shulze’s Here and There. Although I don’t have the poster version, the Wired UK version will do to exemplify what it is:

Here is the idea:

“Imagine a person standing at a street corner. The projection begins with a three-dimensional representation of the immediate environment. Close buildings are represented normally, and the viewer himself is shown in the third person, exactly where she stands. As the model bends from sideways to top-down in a smooth join, more distant parts of the city are revealed in plan view. The projection connects the viewer’s local environment to remote destinations normally out of sight.“

There is more on S&W’s on-line web log where Schulze describes how he wanted to “exploits and expands upon the higher levels of visual literacy born of television, games, comics and print“. More specifically, he wanted to tap into the satellite representation as a symbol of omniscience and the reason why a platform such as Google Earth is so compelling. The point was to have “a speculative projections of dense cities (…) intended to be seen at those same places, putting the viewer simultaneously above the city and in it where she stands, both looking down and looking forward“.

Reading this in the train yesterday made sense when few minutes after, arrived at my final destination in the city of Lyon (France), I encountered this curious map:

The map depicts the city of Lyon from the train station at the bottom (in this white area) and the city itself in the upper part of the picture. There is a lot to discuss here and I won’t comment about what is not represented (can the white part be absent because it may have been perceived as not interesting for tourists?). What I find relevant there is:

• The sort of bird eye’s view, as if we were in a video game, where the landscape is represented in plan over distance
• The color overlay that shows the subway, tram and bus lines is also curious. It basically maps the public transport infrastructure on the perspective
• The map is fixed and located in the train station, it’s only drawn for this specific viewpoint (the station) and definitely match the context of use.

Can the method provide such measurable insight?

Taken from http://www.ryanjacoby.com/

What if your users wrote your business plan?

"Waiting in the lobby of my hotel yesterday in Cambridge, this headline caught my eye.

What if your users / fans / customers actually wrote your business plan or ran your long-term strategic planning process?

How would they change your estimates?

What would that mean from the businesses you'd be in and how you'd invest your money?

Oh yeah, Go Caps!"

Map incompleteness

Map incompleteness is something that I am very intrigued about. As shown in the example above taken in Paris, the city itself is well represented but as soon as you leave the “périphérique” (the highway-like infrastructure that surrounds the french capital), it’s a blank grey void as if no one leaves beyond this limit. It’s a phenomenon you also encounter with weather maps as you can see below: weather forecast generally stops at the border (clouds don’t go through the customs, do they?). You can see the swiss map as if it was a stand-alone territory (lots of countries do it anyway).

Why do I blog this?

Some very useful issues to be thinking about and when and where to use for my own work, if appropriate? Taken from Pasta & Vinegar

"Map incompleteness is understandable in terms of information design: the use of “white space” can be relevant to “balance composition and induction properly”. Designing maps and signage is a matter of simplification so that people could easily grasp the situation at hand. However, in both situations above I am often bothered by the simplification; not that I need to go across the border and would be happy to know the temperature, rather because it discretized phenomena that should be represented as continuous."

Chipchase photo Fare Maps

Fare Maps

Thoughts on Data, design…and soul

Some key thoughts from the blog post ghostinthepixel.com,
it is useful to think of where a model would position itself in relation to this discussion -
Does the model have to be data driven? I would hope not... As pointed out “It is more from engaging with users, watching what they do, understanding their pain points, that you get big leaps in design.” This again is pointing to how a model may lead to such discussions - with the value of data and value of data taken from the context ?
The full discussion is below:

Data, design…and soul

Following up on the initial posting on Google’s “data-driven” ethos by web designer extraordinaire Doug Bowman, and the subsequent heated debate on data vs. design (on ixda, etc.), another web design guru, Luke Wroblewski has published a beautifully compact articulation pointing out the falsity of the debate (which the NYTimes even used in their article title over the weekend–hmm!). Indeed it’s not a conflict, but a parallel dialogue of approaches and viewpoints, working together.

As Luke says:

1. Data informs design
2. A handle on design builds credibility
3. Data is not the only way to make decisions

Nice!

On the same topic, Luke Stevens published this lengthy read teasing apart the issues of “data vs. design”, largely defending data-driven design with thoughtful explanation, but avoiding the typical holy war of righteous indignation.

Ok, that’s fine. However, my issue isn’t really that data drives design or not, but the following:

1. What is meant by data? Seriously. This may sound like a naive question but certainly in light of ethnography, affective studies, personal storytelling, etc (and more from Jane Fulton Suri, Liz Sanders, Brenda Laurel, among others). I’d say the parameters of what constitutes “data” are broadening. I fear there is such rigid attachment by researchers, marketers, engineers to just numerical studies that there is a blind spot to other kinds of data…

In addition to the conventions of web analytics and statistically quantifiable numeric studies/surveys/measurements, there must be room for the data of past professional experience, evolved and applied patterns/principles/guidelines, and yes personal intuition via judgement and thoughtful insight (developed over time with exposure to projects, clients, etc.)

I suspect that a rigid adherence to only numerical data is actually just a snub of contemptuous disrespect for trusting a learned and experienced designer’s judgement, which is multidimensional and dynamic…and evolving.

2. What about the soul of a design? How does extensive numerical data studies enable the aesthetic character, the humanizing quality, the elusive wonderment that makes a design resonate with one’s dreams and desires? “To light a fire in the mind and breathe life into the heart”, as former Sony head of design once described some compelling design concepts, is not something numbers can do. It takes a genuinely inspired and talented human being to elicit forth such qualities in pixels and matter, through a complex messy amalgam of culture, expression, arts, language, style, and so forth. There is an ineffable quality that transcends mere numbers, suggesting a poetic graceful elegance…a kind of equipoise if you will. Hundreds of numerical studies will not provide this no matter how rigorous or detailed. Some of it may be of value, but as Doug Bowman says, “But we take all that with a grain of salt.” And remember… as Jared Spool said once, “any piece of data can be whipped to confess to anything.” It takes the judgement, inspiration, experience, and temperament of the designer(s) to resolve a cohesive blend of the rational and the imaginative into something that people will emotionally connect with and effectively use.

Marissa Mayer may unapologetically say “We let the math and the data govern how things look and feel,” but doing so only confesses the lack of humanity and soul in Google’s products, only a raw Terminator-esque ruthless efficiency embraced by triumphant engineering-centric glee. (Google Analytics–ironically–may be an exception, as is Google Chrome. IMHO per the recent bayCHI talk)

And finally, since when did a numerical quant study alone lead to some of the grand paradigm-shifting, breakthrough products of our time: the iPod, the Dyson, Tivo, Prius, twitter, youTube, blogs and of course the iPhone. Those dramatic jumps of insight more often involve multiple kinds of “data” mentioned above, and the recently recognized skills of abductive thinking (as Frog’s Jon Kolko described at Interaction’09)…with some curiosity and inventiveness and a good measure of perspiration, to hint at Thomas Edison’s old saying. Indeed, from the NYTimes article: “It is more from engaging with users, watching what they do, understanding their pain points, that you get big leaps in design.”