The first sprint wrapped up last week, and I noticed something odd.

I worked with three separate teams of engineers, and I delivered totally different deliverables for each team:

• One team received a full-ish UX spec
• With a second team, we had two hallway conversations
• The third team received wireframe artwork (with no annotations) and then three high-fidelity mockups

Project 1, the full spec

The first project received a full-ish spec, approximately 20-30 pages of flows, composed pages, wireframed components, and lots of annotation. The specification described changes to labels and navigation, changes to an existing flow, a couple new pages, a couple new components, and a couple of pages with small changes.

None of the changes were so complex as to require a spec, and QA is on the scrum team, testing code as it's written, so the spec wasn't for QA. However, the product manager works on the West coast, while I'm in Austin. The changes, though simple, had potential political impediments and needed to be sold, and the changes reflected a holistic shift in the product.

The specification allowed more concrete discussion with the distant product manager, and it also showed how the changes affected the overall, holistic experience of using the product.

However, the spec was probably most likely created because I needed a more visual, comprehensive way to walk through the problems, see the changes, and understand how they affected the whole. I got down into the weeds because it was the weeds that mattered.

Project 2, the hallway conversations

The second project was adding new functionality that was similar to functionality that existed elsewhere. We discussed the scenarios and agreed to use an existing design pattern on the new page.

Unfortunately, using the existing pattern was both a convenience and intellectually lazy. Deferring to the existing pattern and the engineers experience developing the product, I failed to really understand the problem and the context of use meaning that we cranked out a less than optimal design.

Secondly, there was a continuous discussion about where a link to the new page should live. The team kept this topic going most likely because there was no site map of the product that showed what it looked like now, and what it was likely to look like in the future. I'm fairly confident that had we had a site map, we wouldn't have wasted as much time talking about the navigation.

Project 3, the three comps

For the third project, I came in a few days late to consult on best practices and the broader information architecture for a new feature. I was explicitly not designing an interface, nor was I assigned to this project. I was there to sanity check and help the team make sure they weren't engineering themselves into a corner we couldn't design out of later.

The first deliverable were a set of wireframed list components. These were used in a meeting with the engineers to demonstrate the kinds of design requirements that would emerge in the near future, so they could make sure the new services would support them. This was easy and the engineering team was already on top of it.

The second set of deliverables were three high-fidelity designs showing the new components in situ on a client's site. They were created in high-fidelity so the new approach could be shown, explained, and sold to the client.

What every team needs - users, interactions, and interfaces

For any project involving any amount of user experience, the team needs three models: one for the user, one for the interaction, and another for the interface. These models can exist in any fidelity, in any medium, transmitted in any form, but the team needs all three.

Because many applications grow organically over time, a site map is often better than a discrete flow of a single interaction. The site map contextualizes the specific flow illustrating the eco system where your new feature will live. Ultimately, how it melds with the eco-system will have a greater long term affect on your app than how good the actual interface is. The best interaction model is a site map unless the site's architecture is already well understood by your team.

To validate the interaction model and frame interface decisions, you need a model of your user. This can be a persona, a profile, or a role, though the important parts are the user's experience, how often they'll use the interface, and why. The experience and frequency of use you can state, but the why requires a bit of story: what incites the interaction, what else is happening while they perform the interaction, and what obvious problems will they encounter. Explain those three pieces of the story and you'll have a solid framework for understanding your users.

The model of the interface is least important. Mistakes in the interface are almost always made because either the user or the interaction are misunderstood. They key to working in a more agile way is to give everyone the strategic context they need to make good tactical decisions. With this context and a shared understanding of design patterns, anyone on the team can make good interface recommendations.

Information architecture believes in creating places for experiences to happen. It doesn’t believe in telling you what those experiences should be or what you should think about them. It believes in architecture. It believes in cathedrals and bazaars. Information architecture believes in people.

A code of conduct has two problematic assumptions. First, the community that presumes to create the code presumes to predict that future versions of itself will have the same values, express them the same way, and expect to manage violations the way violations are managed now.

Even worse is the second assumption: creators of codes of conduct believe they have the right to obligate future generations to the code of conduct they would identify today.

Not to mention, codes of conduct are never embedded with mechanisms for evolution and adjustment. Codes of conduct are always edicts, set down now and forever, presuming the future and the creator's own wisdom and discounting everyone who will follow, as if now, at this moment in time, we would suddenly know more than all other moments in time.

Statements of values

Wisely, some, sensing the problems with a code of conduct, have tempered their critique with an alternative: a statement of values.

A code of conduct is built from negatives: these are the things we do not do. These are dangerous things. Even if the code is stated in the affirmative, it is constructed of negatives. A code of conduct is exclusive, meant to exclude those who violate the code.

In contrast, a community constructs a statement of values from affirmatives: these are the things we believe. A statement of values is inclusive. All those who will prescribe to these values will be included into the community. If you believe fire is a dangerous thing, then you are one of us.

With a code of conduct, a violation is a violation. There is no adjudication. A code adjudicates an action as a violation or not a violation. It is a dangerous thing, or it is not a dangerous thing. Judgement is prescribed only to the sentence.

In contrast, where a code of conduct requires correct actions, a statement of values requires correct beliefs. Where a code of conduct only requires judgement of the sentence, a statement of values also requires judgement of the action. Yes the violator's actions may have violated our values, but do they still agree with our values? Yes, they may have done a dangerous thing, but do they still believe fire is dangerous?

Future tense

Where a code of conduct presumes to divine the future, a statement of values presumes to step out of time, to describe a pure and true comprehension of a community's culture. As human experience is embedded in time, assuming one can step out of time is like a fish explaining to an earthworm what it's like to be roasted alive and eaten by ants on a sidewalk in the Summer sun. In all the oceans and all the seas, there is no fish so prescient, and any fish who realizes this truth dies from the epiphany.

So, we have three problems:

• We cannot predict the future
• We cannot obligate the future
• We cannot avoid the future

What we have left is the past. We should not explain what we will do. Nor should we explain what we believe. Rather, we should describe what we have done. Our tribe need not mandate what actions make a tribe member. Nor should we mandate a creed. We need only tell our history.

Past perfect

How should we act? What do we believe? I don't know. But I do know our history. What I do know is that Saturday evening, I saw children playing games. I saw a child sing at karaoke. People brought their children to the conference. And, our metaphorical children, first-timers, are actively recruited to speak, trained in a speaker studio, set-up for dinner, applauded in public, and roundly welcomed.

Four years ago in Memphis, one of the memes was that "our women speak", and our history is filled with leaders like Christina Wodtke, Karen McGrane, Samantha Bailey, Sara Rice, Livia Labate, Mags Hanley, Erin Malone, Abby Covert, and Whitney Hess. Our women are not the exceptions that prove the rule. Our women are the rule.

So, Sunday morning, while you gather with good intentions (and I've snuck onto an airplane to go home and see my kids), I hope you don't try and tell future newcomers what they can and can't do at some unknown point in the future. And I hope you don't try and tell us what we believe.

Instead, I hope you tell our history. I hope you talk about your first Summit. How it was more like a confab than a conference. How we welcomed newcomers more than old-timers. How we talk more about ideas than about javascript. How we share stories and wisdoms more than we share rules and truths.

You need a code of conduct if women are dangerous things. If you never know how they'll react, if you must temper future behavior to avoid their danger. You need a statement of values if you believe women are like fire, able to warm you or burn you, and that they require a cosmology to understand the difference.

We need neither. Our women are neither fire, nor dangerous things. Our women are just a part of us. They're a part of our history. And our history is all we need.

I’ll be at the 2013 I.A. Summit in Baltimore, April 3-7 where I will be speaking cross-channel user experience.

About the presentation

User Experience in a Cross-Channel World

One of the dirty secrets about cross-channel UX is we’ve always worked cross-channel. What’s changed is how much — and how well — we can impact the cross-channel experience.

In this presentation, I’ll share lessons learned since my first cross-channel project eight years ago. Those eight years have revealed three principles that should guide all of your cross-channel work.

With those three principles in mind, we’ll examine four tools you can use to help guide and improve the cross-channel user experience at your organization. We’ll include real-world examples, as well as templates you can use to integrate these tools into your process.

Once we’re done, new and intermediate-level designers will have added a set of tools and strategies to their toolbox they can use Monday morning. You’ll have learned how to mold better experiences across your entire organization.

Please join me at PhillyCHI on February 7 as I make a brief stop in Philadelphia to talk about how agile, lean, and waterfall design teams can maximize design value in different situations.

About the Presentation

The Design Age:
Or, A young designer’s primer on maximizing value for lean and agile teams.

Design is all about value. It helps transfer value from one person to another. Design insures you have an experience: that at the end, you’re different than when you started. Design makes this difference, and like Babbage’s Difference Engine of yore, specific knobs and levers control how much value you can create with design.

In this presentation, we’ll learn how five levers — models, fidelity, audience, annotation, and velocity — work together. We’ll see how agile, lean, and waterfall teams apply these levers differently at different times to create different value from design.

Friday at work, you won’t be able to stop yourself from asking five, simple questions. You’ll be maximizing design value for every project you encounter.

About PhillyCHI

PhillyCHI is the Philadelphia regionʼs chapter of the ACM SIGCHI, an interdisciplinary academic and professional group interested in Human-Computer Interaction, User Experience, Usability, and other related disciplines. PhillyCHI holds monthly meetings and socials to network and discuss current topics in HCI. Learn more at phillychi.org or follow along on Twitter at @PhillyCHI.