The road is paved with good intentions

There's an interesting discussion going on at Chad Meyers' blog about quality in both design and execution. Chad argues there is such a thing as Good Design, that knowledgeable observers can reliably discern its presence, and that "but it works!" is not a defense or justification for bad design choices.

The bad design characteristics Chad spotlights prevent teams from responding effectively to demands on the application. With each release the team is less and less able to respond until they are locked in to long projects that deliver little incremental value. How do teams start down the path that leads there?

Chad's post hinted at an important consideration that doesn't seem to get enough attention. Too often people make fast delivery of finished features the top priority, then define everything else as speeding up or slowing down delivery. The problem is that driving to "finished features" (where finished = fully realized) prevents the team from engaging in "fast fail, fast feedback" cycles. If there is also a stated desire to work in an "agile" fashion the team might try to marry the "finished feature" driver with a short-timebox approach with disastrous results. On a large project few fully-realized features can be started and delivered in a single 2-4 week period.

The Agile team will look for a way to decompose the desired end feature into meaningful chunks and distribute the work across the team such that each 2-4 week period delivers a coherent, complete piece of functionality. The wish-we-were-agile team calls on the team to keep the feature "simple," not to "gold-plate" it. Once headed down this path all kinds of things become gold-plating - error handling, usability, even the goal of working software can be set aside under the banner of producing "good enough" software quickly.

Of course there is nothing wrong with "simple," "good enough," or "rapid delivery." Problems arise when the team identifies "simple" feature realization and "simple" process with undesigned, untested and incomplete. The team might find itself choosing to hack up a feature, not because it's a justifiable approach given the business needs but because their inability to decompose the feature and plan across iterations has created an artificial pressure to cross the feature off the project plan. That team can report that features are "done" but pays the price later when the customer doesn't accept the feature or the market demands more.

Read more...

Designing for the Edges

"Explore your edge cases for the sake of innovation."

Nick Finck is just one of the prominent designers who see the value in edge cases. On the other hand, the casually dismissive "Oh, it's just an edge case!" is all too commonly heard. Before tossing out your edge cases altogether, ask these questions:

• Is the case a user goal believed to be shared by only a few users?
• Is the case created when technical limits prevent the application from fulfilling a user goal?
• Is the case created when users interact with the application in unexpected ways?

If the answer is "Yes," the edge case indicates the opportunity to introduce delighters/exciters, usability improvements, technical innovation, or trend-anticipating product innovation. Capture this information somewhere for follow up if you must drop the case from your current design effort.

I saw these factors in action some time ago when I was designing a new, much-requested, feature. One customer had what some believed to be a novel requirement. The requirement seemed to make business sense. The solution would extend an existing feature and require the addition of a minor option to the feature I was designing. Even so, my business stakeholders asserted this customer's request was wholly unique. They were sure no other customer would use the new option because, the stakeholders believed, none of them used our application the way this customer did.

I decided to inquire further. After all, these same people had asked us to invest a significant part of the project budget to design a different capability targeted at the very use pattern they now were sure was used by only one customer. It didn't add up.

Sure enough, there were customers who had asked for something similar. Engineering had not anticipated their requirement in their original design. Later, engineering removed a configuration option from a related feature. Without the configuration option, the first feature was unusable.

Someone had figured out a hack that mimicked the desired behavior, a hack that was subsequently employed for other customers. The hack was "good enough" - until a customer needed both the original feature and the flawed related feature. The workaround obscured an underlying limitation in our application that could have been easily remedied at any time.

This "edge case" qualified on all three criteria: people believed the request was idiosyncratic, a technical limitation prevented solving a customer's business problem, and the need to solve the business problem was unexpected. By repairing the flawed feature we could serve the insistent customer to their satisfaction, and deeper-than-face-value analysis revealed prospective customers would likely appreciate the feature, too.

Read the 4-part series Designing for the Edges at Functioning Form, where Luke Wroblewski collected a number of perspectives on the value of edge cases.

Read more...

The new manager is a designer

Since My ScrumMaster training, as an experience designer and manager I've been thinking a lot about the value of those roles. At first I was tempted to think that Scrum meant organizational managers are obsolete. How could they, after all, do anything but obstruct the Agile organization? Well, Agile is onto something there - but if so, it's to expose most companies' failure to value and develop an effective management practice.

I've decided that every manager's job is to create an effective organization. If a manager isn't working today to help the whole organization work smarter with better results than it did yesterday, that manager's company is not deploying its headcount for highest business value.

My first stint as a department manager gave me an established team of programmer/analysts and help desk analysts. As it happened, the company relied on me most to manage projects and tasks the department's members were working on. To the people who reported to me I was an interrupt-managing interface to the rest of the organization.

Something didn't seem right. What of serving a team that is effective and satisfied, proud of their accomplishments and continually learning and growing? What of moving beyond caretaking or task management to finding new ways to add value? It seemed that outside of the budget and annual reviews (to which most employees and managers paid lip service) department management seemed to exist mainly to relieve the administrative burden of higher-level managers.

I went on to do my tour of duty as a consultant. I watched project managers create and shepherd projects that delivered value-generating products. I watched product managers deploy that product to realize its power in the marketplace.

In a seemingly unrelated activity, I've been designing a BPM application in which reporting relationships and organizational structure can be used for various process management purposes. In the the world of workflow, organizational units become active delivery mechanisms of essential resources.

Now all the pieces came together. Project managers deliver products via projects. Product managers deliver revenue via products. And organizational managers deliver effective human systems for deploying expertise, coordination, authority, and responsibility. To do so, managers have to design experiences and interactions.

As it happens, I've been seeing quite a lot of discussion pointing to this very conclusion. Next month Richard Buchanan will speak on management as design in his presentation The Four Orders of Design at the Design Management Institute annual conference.

I'm both a designer and a manager; expect this topic to become one of the main themes here.

Read more...

Product Design Matters

Luke Wroblewski (Yahoo!, Functioning Form) talks about the strategic importance of product design at SHIFT 2006 (Lisbon).

Read more...