Business of Design from Thinking and Making

Wilson Katter's Business Deal Basics

Austin Govella — Tue, 02 Sep 2008 12:11:00 GMT

Recently, David Maister ran this fantastic post on Wilson Katter's "Business Deal Basics". Lately, I've been mulling over the idea that design is less about designing the interface and more about designing the organization that designs the interface. Wilson Katter's basics speak to ways designers can better design the organization. Katter has graciously allowed anyone to circulate his ideas providing you acknowledge his authorship and copyright. I've copied them below hoping that would make you more likely to read them. Also check out David Maister's site. (He has a new book out!)

Wilson Katter's Business Deal Basics

To avoid many of the problems which arise in business relationships, here is a set of prerequisite criteria with which all parties should enter the discussions/negotiations.

Much time, money and effort can often be spared with the conscientious practice of these criteria. Without them, the negative impact of misunderstandings, aggravation and emotional wear and tear can also sometimes cause an almost incalculable loss.

The goal of a win/win result, defined as such by all parties
The skill of understanding the position of all the parties
A keen appreciation for the relative value which each party brings to the equation
The use of reliable, authoritative resources
An “I may not know it all” attitude
The willingness to have “facts” challenged
Finely tuned listening skills
Consideration of all points of view
Impeccable integrity
Transparency and honesty
Keen analytical faculties and good judgment
A mature sense of fairness
Compliance with high legal, ethical and moral standards
Clarity of both oral and written communication
Timely replies/responsesin the exchange of information
The ability to “disagree agreeably”
Humble acceptance of the required modification of one’s position
Patience to do it right the first time so it doesn’t have to be done over
Equitable compromise without the sacrifice of principles
A long-term perspective which looks beyond the near-term benefits
Respect, respect, respect

REMEMBER, IMPROPER MOTIVES WILL MOST LIKELY KILL THE DEAL.

ALTHOUGH CHALLENGING AND SOMETIMES TOUGH, DOING BUSINESS THIS WAY CAN HAVE THE GREATEST REWARDS.

Agile + UX = idealized vs. current state

Austin Govella — Tue, 08 Apr 2008 16:03:00 GMT

Please listen to the attached soundtrack whilst reading the following.

Agile really likes to focus on iteration. For a lot of developers, this is code for biting off small, manageable, deliverable chunks. Small, manageable, deliverable chunks is not necessarily the same thing as iterating on a design.

They _can_ be the same, but they aren't _necessarily_ the same. Regardless, this means the current state of your product is not the same thing as the envisioned state. This is true for almost every product development process, but agile can make this more of an issue.

How iteration works in the agile process

One of agile's tenets is that you release small changes to a product frequently, instead of major releases less frequently. The agile sprint is a cycle as short as two weeks where the team is supposed to develop, test, and release a feature in its entirety.

Say you wanted to add forums to your site. By itself, this might take three weeks worth of work. A small, manageable two week task might be to add a way for users to register their email address. At the end of the sprint, the team would expect to release the next version of the product that includes user registration. On the next sprint, developers might release the back-end updates necessary to handle the forums, and two weeks after that, they might release the front-end interface that allows access and participation in the forums. During these three example sprints, everyone knows the ideal state: forums on the site. And each sprint moves you closer to this ideal state. However, iteration requires two corollary management tasks. First, you have to communicate the ideal state to the team. Everyone needs to have the same shared understanding. Second, you need to track the gap between the current design and the ideal design.

Communicating the ideal state

I'm totally thinking "this is why we crank out wireframes".

To clarify for any non-UX people reading this, drawing, annotating, reviewing, editing, reviewing, approving, communicating, and clarifying wireframes is not the sexy part of the job. Sure, some people really get off on that sort of thing, and I make a point to wear fishnets any time I open Visio, but most practitioners do wireframes because they have to so they can communicate the shared understanding of what the product is _supposed_ to be. Let me be clear. Deliverables are not teh sex. Teh sex is what _leads_ to the deliverable. (Someone -- who shall remain anonymous -- put it this way: "Toddlers are awesome. Poopy diapers suck. Wireframes are the poopy diaper that happens after your toddler has eaten a great meal.") Of course, this doesn't have to be a 500-page spec. Doesn't have to be wireframes. But it has to be something. Even a photo of a whiteboard session that everyone has access to can work. Whatever it is, it has to be something.

Minding the gap

You can't mind the gap unless you have two sides to point to. One side is the current version of your product, and the second side is the idealized version.

While your agile team is iterating on the current state and marching towards the ideal state, someone has to keep track of what has and hasn't been built. This seems silly. I imagine agilists saying that the smart, unfettered, goal-centered team members will manage the gap. Sure. I suppose they could. In my experience they don't. Nothing against _them_. I'm one of _them_. And even being heavily invested in "my baby", I'm not minding the gap. This ties into my post on parallel work streams where I mentioned the sprint support role that's emerged at Fancast. Everyone is busy doing something. Engineers are developing. IAs and designers are designing. Product's reviewing, tweaking, and iterating. It's really pretty awesome. But, if a feature is limited so that it will fit into the current sprint, all of a sudden you have two features. You have the edited version being built, and you have the ideal state you _hope_ is coming. If the functionality is different, you need two shared understandings: one for now, and one for later. Now stay with me. We're imagining rolling sprints. This sprint, a small portion of a feature, an edited version of the feature is built. Next sprint, you build the next version. Or maybe you don't. Maybe the iteration isn't as important as launching another small feature. Agile lets you turn on a dime, and you've just turned. The ideal state falls into that ghetto, the sprint backlog. Who remembers that ideal state? The team's busy with something else now. And what if you've got really lean documentation? There's a gap in organizational memory. And it's not minded.

Dirty laundry. Look away. Do not read any further

Here's a dirty little secret from where I work.

Let me set the scene for you. Engineers? Rock stars. Seriously. In the IA group we have engineer love-ins where we talk about the engineer we're crushing on this week. The product team? Fucking brilliant. Seriously. They just get it. Everything. And the IA team? If I may say so myself: fucking awesome. (And, no, I am -- by far -- *not* the only IA on the team. But, for the record, the _entire_ IA team at Comcast Interactive seriously kick ass.) So here's the dirty secret. Back in September we wireframed a new version of the preferences section. In October we "iterated" on the first wireframes, which really meant they were totally redone. Each time, they were bumped off the next sprint by other things. We're redoing the wireframes a third time right now. It's not the people who are the problem. We've got good people. And it's not the project. The prefs aren't particularly sexy or ground-breaking. We just don't mind our gaps very well. Or at all, really. But if you're doing agile, you have to mind your gaps, or you'll forget where you're going. Heck, if you're moving really fast, you'll forget what's actually made it on to the site.

Agile + User Experience = Parallel work streams

Austin Govella — Mon, 07 Apr 2008 16:00:00 GMT

There's a thread on the IAI-members list about how agile and user experience work together. We're using an agile dev process at Comcast, and it's been the source of some frustration, so I was kind of snarky about some of the problems I've faced. Snarky's not constructive, so, as a penance, here's something I've learned. Like anything, agile works or doesn't work based on the people you have, and the culture they function in. (Everyone can now say one giant, collective "duh".) Regardless of whether it does or doesn't work for you, I've noticed most environments require parallel work streams.

Why parallel workstreams?

Though Agile pretends to eschew documentation, it really wants to avoid unnecessary documentation. Agile likes lean. Do only what you must. This doesn't mean no documentation. The team still needs a shared understanding about what it's building.

In that sense, it's better to refer to documentation as "shared understanding". Whiteboards, napkin sketches, daily scrums, and annotated wireframe decks all provide shared understanding. (In my experience, too, the more people who will see the "shared understanding", the more time documenting the "shared understanding will take. Not an inherent truth; just an observation.) Product managers and UX practitioners still need a vision. And, it's still vitally important to examine possible impacts. (For example, how will this new feature affect flow through the site.) To that extent, *planning, design, modeling will always be necessary prior to development*. Erin Malone mentioned several Yahoo teams have started a Sprint 0 with upfront planning. At Comcast, we don't have an official sprint 0, but there's a parallel product development track that dumps something new on to the sprint backlog. Essentially, they're both the same thing: Plan before do. For incessant waves of sprints, this means you design work for the next sprint while supporting work on the current sprint. With Fancast, supporting developer UX needs (answering questions, clarifying, collaborating on additional iterations) has become a full-time job. Someone else (or several elses) design features for the next sprint. (There's a fall-out assumption here: planning and design require more product, UX, and design folks than implementation does. Everyone can now say one giant, collective "duh".) There's a danger here. If you do not accurately communicate how much work you have and how much you can do, you can get sucked into doing more than one person's worth of work. That is, you support the current sprints UX needs, and you design all of the work for the next sprint. That's a lot of work. This isn't a problem with agile. This is a problem setting expectations and communicating status. However, I think agile can make this problem more likely. With agile, the focus is often on development time. A feature might require 10 hours of development. It's possible to require more than 10 hours to plan. It could take less. Again, it depends on the amount of shared understanding, the design literacy of your team, the actual impact the feature has on the current project, etc. If you have four 10 hour development features, and they each require more than 10 hours of planning time, then you cannot crank out enough design work to keep developers fully occupied next sprint. Parallel work streams require very clear expectations and status regardless of the development process you're using. Using our above example, it's imperative you're clear that planning a feature will take longer than you have. Similarly, if planning suddenly requires more or less time, you need to communicate this change right away in a clear manner. Thankfully, on top of being lean, agile is also about constant communication. That's my experience. The big unknown is whether it's possible to support a rolling series of sprints without parallel work streams. Anyone seen this in action?

Assessing your team's UX skills

Austin Govella — Mon, 17 Dec 2007 05:11:00 GMT

Jared wrote such an awesome article over at UIE, I'm actually posting: Assessing your team's UX skills.

The best part isn't the assessment. It's his breakdown of core and enterprise UX skills.

Changing the Channel (interview with Livia Labate and Austin Govella)

Austin Govella — Sat, 15 Sep 2007 20:04:00 GMT

Last March at the IA Summit, Christina Wodtke grabbed myself and Livia Labate for a quick discussion about how information architects can better interface with the business.

I'm a few months late on mentioning this, but our interview inaugurated Boxes and Arrows podcast series, 'Straight from the horse's mouth', that also included great interviews with Behavior's Chris Fahey, Dan Brown, Yahoo's Tom Wailes, and Derek Featherstone. (The interviews are no bullshit, Summit conversations captured in little audio time capsules.)

One of the reasons I wanted to work with Livia at Comcast Interactve Media is because she has the amazing ability to enter a conversation, immediately understand the key issues, intuit exactly how the participants need to be spoken to, and then say the perfect thing at the perfect time.

For anyone in any service industry, this is THE skill to have.

And of course, Madame Wodtke wields this same magic. Her summation of the interview with me and Livia?

Learn the language
Lose the agenda
Be a resource
Dress better

If you don't speak PowerPoint, that translates to learn the language of business, lose the user agenda and focus on what the project needs, become a trusted and dependable resource for the business, and if you look like you're on the business team, you'll have more business conversations than design conversations.

That's the gist of it. The complete interview is up at Boxes and Arrows. Straight from the horse's mouth: Changing the channel.