I've moved my blog over to agux.co.

To preserve URLs, previous content will remain archived here, and I have already begun posting new thinkings and makings at agux.co.

To make it easy for RSS subscribers, I've done some magic feed redirection, so you don't have to do anything for your feed reader. The new content should automatically begin to populate your feeds.

Nine years ago, I wanted to be an IA when I grew up. This is what I wrote:

"But I don't want just any job. I want my dream job. I want to work for an agency that handles a diverse number of projects in a diverse number of industries. I want to work for a design company, or a company with a large design department, where they appreciate the advantages design brings to the table, where they understand that design is now a required component of good business.

To get me to my dream job, I need several things: there a couple of holes in my portfolio; I need a network of professional colleagues (how else do you land the dream job); I need my colleagues to know that I know what I'm doing (and that I'm damn good); and I need suitable resume fluff that says the same."

I'd met my goal roughly two years after writing this. And it probably took five years, total, from start to finish.

This is why anytime anyone comes up and tells me about their similar dream, I give them the advice I took for myself: get a network and do good work.

The UX Zombie survival guide, an introduction to hacking user experience for agile, lean, and waterfall teams.

This is the presentation I gave at Big Design 2013 on Hacking UX Zombies. It's a shorter version and more of an introduction to the longer Hacking UX presentation/e-book I presented at Agile 2013.

All our lives, we’re told the barrier to keeping our commitments is not knowing when to say no. That’s only half of the story. Commitment is also about knowing when to stop.

My curiosity and ego are strength as well as weaknesses. I grew up believing I could figure anything out, and with my curiosity, anything is interesting enough to figure out.

I’m curious in more things than I have time to explore.

We’re going through annual reviews at Avanade right now. Familiar comments pop up in my feedback: be on time; deliver on time. The quality of my work is good, I work well with my teammates, and I have good relationships with my clients. The problem isn’t the quality of my work as much as it is the quality of my commitments.

For September, I heeded the principal instigator’s call to write 500 words a day. I sat down to write this evening, and there I was cruising past 500. And then I stopped.

It’s not that I didn’t have more to say. But the commitment was to write 500 words a day. I may have more, but I committed to 500. 500 is enough to deliver, and if I keep writing (like I am now, ironically), then I won’t have as much time for another commitment at home or at work or personally.

Commitment is about knowing when to say, “no”. Commitment is also about knowing when to stop.

So, I’m stopping now. Going to do a couple of edits, hit publish on the first 500 words, and then spend some time with my loved ones. Tomorrow, when I’ve committed to another 500 words, I can write some more.

One sprint, two products, three teams, and three different ways to integrate UX. It may have looked different, but the UX process was really the same.

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.