In the first part of this two-part series, we talked about what Stories are, their relationship to Personas and Story Maps, and factors to consider when writing stories.  Let’s continue by looking at the relationship between stories and UI exploration.

6. Iterate Story Development with UI Exploration

Within the everyday chaos of an average design project, part of what makes stories so valuable is their nimbleness and flexibility.  They can easily be ordered, re-ordered, and grouped in any number of ways depending on your current need, such as by category, priority, complexity, sprint, or whatever, and you can do this in a highly ad-hoc manner.  Team members can use the same card for everything from affinity diagrams to product road maps to scrum boards and on and on. But this level of flexibility also has drawbacks.

The node-like nature of Stories also means they often lack context.  In other words, while you can easily group a set of cards and say that they belong together, it is very difficult to see how they will fit together simply by looking at the cards alone. This is where UI exploration comes in.

Users participating in a design studio session

While Agile offers strong conversation-centered methods for capturing stories, UX adds to that by offering visually centered methods for contextualizing those stories, i.e. helping us uncover the order in which features should be completed, which feature should be accessible in association with other features, and more.

Here’s a quick example. Jim, the auto mechanic we talked about in part 1, has described each of the following features as being important to him:

(Note that we are not using the long format described earlier. Especially during early exploration, just have users jot down short phrases they can speak to in more detail later.)

Discussing these features with Jim, he explains that

Sometimes I want to search by part number, but sometimes its easier to just find it based on where in the engine the part is, especially for new models, though sometimes I might need to find the part based some other spec info, or all I have is an aftermarket part number.

Based on this conversation with Jim, while it is clear we have a good starting point, it is also clear that we have no idea if this list of features is the right list or a complete list until Jim is able to see them in context, i.e. in some rendering of an actual user experience.

For example, maybe we create a part number search feature with a smart auto-complete, which when Jim sees it, he realizes that a visual search is not as critical as he thought.  Or, conversely, maybe we make the visual search so easy that searching by part number falls to the wayside.

The bottom line is this: make sure UI exploration is part of story development.  For example, do some initial cardstorming with your users, but then quickly transition to a visual exploration, such as a design studio. (Will Evans recently did a great write-up on on that.) The visual exploration will also help you improve your story coverage.

Story coverage is the degree to which you in fact have all the stories that will be needed to deliver a complete product experience.  This can be very hard to see from just looking at a list of cards, but is much more likely to jump out at you when looking at or interacting with a user interface.

7. Make sure UI infrastructure stories get into the backlog

If you are using a story-based model for software development, that means that only features for which there are stories, and which have been added to a sprint backlog, will in fact get implemented.  Ok, that’s all good and well, but what does that have to do with UX?  Well, it means that simply having a feature appear in a wireframe or prototype, even if the team agrees that the feature is important and should be part of the product, does not mean that feature will get built.  There must be a story for the feature, and the feature must be added to the backlog. If not, you’ll be negating much of what makes a story-based model effective.

Now, in most cases, this is not a problem.  The force driving the creation of a set of wireframes is usually a set of stories.  Or, in other situations, you might start visually, and then generate story cards from those artifacts.

But in the midst of this, there are certain features which can easily slip through the cracks, which I like to think of as UI infrastructure stories.

Like signage in a building, some UI features are just seen as part of the infrastructure, and something customers will just expect to be there and not think to ask for.

These are your water-sewer-electricity-type features, like pagination for tables or navigation bread-crumbs. A product owner isn’t going to think to ask for this stuff, but will simply expect to see it in the product, like I am not going to ask for electrical outlets in my hotel room, but will just expect it.

The problem here is that, in a story-based model (and in some ways in the Agile model in general), if you don’t ask for it, you won’t get it. But UX design, in contrast, is very much about giving the customer what they did not think to ask for.  Therefore, as part of UI exploration, it is essential to look at the UI and compare it to the backlog and make sure that there are cards for these types of features.

Find these features in your design artifact, write a story for each of them and work with your team to get them estimated and added to the backlog.  If not, you are going to have some unpleasant surprises at the end of your sprint, and be carrying UX debt, i.e. half-baked experiences that, like credit card debt, get costlier and costlier to fix with time.

8. Be present during story estimation

A key function of user stories are to serve as an estimating and planning tool.  After stories are written, hopefully by customer and users, developers use a variety of methods (such as planning poker) to assign a cost to a story, such as in the form of story points, such that the Product Owner can decide if they want to “buy” it and place it into the backlog.

Conventionally, only developers, or those who will be doing the actual software construction, participate in estimating.  That is all good and well. (After all, something that may seem as simple as justs adding a button to the screen from a UI perspective could equal a world of work that we are not aware of under the hood.)  At the same time, it is critically important that you are present during estimation.

And I don’t just mean physically sitting there watching developers estimate (though that can be an experience in itself, if you’ve never seen an Agile estimation workshop), I mean really being present.  In other words, come prepared to an estimation session with an idea of which cards you think might involve some complex UI, and watch out for a low-ball estimation.  Make sure you educate yourself on how Agile estimation works, so that you can raise a concern if you think developers are under-estimating a feature.

A common pattern, particularly on a pragmatic Agile team, is that the estimation will be based on the simplest possible way to implement the feature.  For example, if you are implementing a form, that may mean just putting all the fields on one page as one long form.  However, that may not be the best solution from a UX perspective.  You should be present to lobby for a more costly but also more user-friendly UI, in cases where it makes sense, such as to make the product competitive. This is also why its so important to have done some UI exploration before you estimate, to have a concrete basis for your discussion. Too often I see it happen afterwards, which makes for all kinds of churn and other problems.

9. Make sure testers are testing for usability

From a tester’s vantage point, a story is something for which you create a test.  If the test passes, the story is done.  Ok, I’m oversimplifying things quite a bit here, but one thing to be aware of is that testers in many cases are not looking at or primarily focused on the user interface. Instead, they are writing code-based tests that check to see if the code written to execute the given feature passes the test or not.

A snippet from a code-based unit test, which would run as part of automated testing.

If your head is spinning from reading that, then you would be well advised to educate yourself on test-driven development.  It turns traditional QA on its head and is a powerful manifestation of Agile thinking.

Perhaps more importantly from a UX perspective, because it allows for a large percentage of testing to be automated, it can free up testers to spend time reviewing the user interface and the quality of the user experience.  This can, to a large degree, be a question of working with them to point out examples of the types of issues they should be looking for in the UI, things that might jump out at you, but may not jump out at them, such as pagination links being super-tiny or in a color that is hard to see or whatever, but also to make sure that they are looking at and comparing UI screen mockups with the real thing.

It also means looking carefully at any acceptance criteria that have been created going into the sprint, because testers will use those as a basis for determining done-ness. Another very powerful tool here is a UI style guide.  This is where you can include general display rules for the user interface, so that you don’t have to keep repeating the same issue over and over.

This will allow you to spend more time working on the design for an upcoming sprint and spend less time having to check every screen of the app at the end of every sprint and nag deveplopers (or fill out time-consuming bug reports) about a slew of small tweaks that need to be made.

10. Read Mike Cohn’s book

User Stories are a huge topic and I’ve only looked at them here from the relatively thin perspective of UX.  If you haven’t done so already, you should pick up a copy of Mike Cohn’s book, User Stories Applied.  Even though it’s been out for quite a few years now, it remains as relevant as ever.

Any tips and tricks for integrating UX and User Stories you’d like to add? Please share them in the comments! 

Users reviewing stories on a card wall

If you are a UX designer who wants to quickly get up to speed with integrating Agile and UX, there are few better places to start than with User Stories.  They are both a quintessential embodiment of Agile thinking (i.e. if you understand User Stories, you understand Agile thinking) and a potential power tool for a UX designer on an Agile team.  But like any tool, they can be highly effective, or, if you have no idea how stories work, cause some serious damage, especially to the UX dimension of your product.  So, if you’re using User Stories or thinking about adopting them as a tool, here are ten tips to help UX designers understand User Stories (we’ll just call them Stories from hereon) and wield them to both yours and the team’s benefit.

1. Know What the Story Is

Ok, first things first.  Before we can offer any advice about stories we need to understand what we’re talking about. Take a look at this and tell me what it is:

If your practice has been raised on a steady diet of document-centered design processes, i.e. work that revolves around and culminates in the creation of documents, like specifications or use cases or whatever, you can be forgiven for looking at the above card and thinking that you are looking at a story.

The card is not the (whole) story
Yes, the above definitely is a story card, but the actual story is not on the card.  This might be confusing, but bear with me here.  The statement on the card is only what one can think of as the title portion of the story. The full story is the conversation triggered by the statement on the card.  In other words, the complete story, i.e. all the excruciating details about the given feature, live in a self-maintaining, self-updating data store, namely the team’s collective memory.  Therefore, in whatever moment when someone picks up a card and has a conversation with other team members, the statement on the card triggers the most current knowledge about the feature by those team members.

The idea of storing project information in collective team memory might sound funky, but not only does it make a lot of sense—information in a modern software project is too fast-moving and volatile for document storage to be able to keep up—but collective team memory is, by its nature, always up-to-date.  All that is needed are the correct words that will trigger the appropriate memory, and resulting conversation.  And that is what goes on a story card.

If you’re still skeptical about this concept, you should know that you probably use this technique yourself on a regular basis, such as when writing a todo list. When writing a todo list you don’t write down every last detail about the thing you need to do, but only just enough so that you won’t forget to do it and, when the times comes to complete the todo item, you’ll remember all the details about what needed to be done.  Stories work the same way, except that in this case its a team-wide todo item, as well as a team-wide communication device.

Stories are a whole-team communication interface

Each team members looks upon and uses the same story from the vantage point of their particular work

When you hand the same card to a different team member, each team member will look at it from a different perspective, and use it in a different way.  In more pontificating terms, this is what is known as a boundary object.  For a user, it describes a needed or desired feature.  For a developer, it describes a feature that needs to be estimated and/or work that will need to be completed. For a UX designer, it describes a puzzle piece to be fit into a product offering (or not) to create a coherent and valuable experience.  For a tester, it describes something for which a test likely needs to be written.  And so on, for each team member.  One story; multiple perspectives.

If you understand these various perspectives and the way in which a story gets kicked around between team members, then you’ll have a good mental model of how the Agile project game is played, and where you can best position yourself on the field to move the story to the finish line.

2. Make Personas the voice of the story

In contrast to old-school requirements, which are written from the perspective of computers, i.e. “The System shall…” do this or that, Stories are written from the human perspective, e.g. I want to be able to do this or that.  This shift in perspective is a great example of how Agile is much more human-centered compared to waterfall.  But when bringing UX practice to Agile, we have an opportunity take this even further, as part of integrating Personas, by making the Persona the voice of the story.

In other words, if we do a Persona workshop in the early stages of the project, each story that is created should correspond to one or more Personas.  Let’s say our substitute teacher persona is Becky. After putting in all that work into modeling Becky, we can now leverage that in how we create and talk about our stories.  For example, we can add a Persona prefix to our story statements:

With this short prefix, we’ve both made the user feel more real, and in conversations about this story, we can talk about what Becky would want or not want, rather than what some anonymous and disembodied substitute teacher would want.

3. Have users write the stories, not you

For an advanced Agile team, this is Agile 101, but if you’re new to Agile, you may be sitting there frantically trying to write story cards while users are telling you what they want.  However, a key aspect of an Agile approach to engaging users or team members is active collaboration and creation of artifacts by the team rather than by individuals.  In the case of stories, this means that you create contexts in which users write their own cards.  There are numerous ways of doing that.  One is the Paired Interviews technique I wrote about recently. That, in turn, is a type of cardstorming activity, which more commonly is done individually, with each team member creating as many cards as they can within a short (e.g. 5-minute) timebox, followed by self-organized group chunking and prioritizing.  Additionally, the overall project infrastructure should be such that cards are available at arms-length virtually wherever you are working (e.g. place cards and markers at the center of every table, and scattered strategically throughout your team room), such that you can capture cards at the speed of conversation.

So why is it so important that the users write the stories?  One main reason is that they will then phrase the card in their own domain-specific language, and in a way that is likely to most effectively trigger the appropriate memories when you ask them about the card down the road.  And on that note, if the cards are written by hand, their handwriting can be used for card traceability, i.e. you’ll be able to know who wrote the card just by looking at it.  And if you are gathering info from many users, well, then they will be able to produce far more cards as a group than you could on your own.

4. Be sure to get your “so thats”

As you may have noticed, the above cards are written in what has become a standard structure for writing stories:

Now, while there is nothing that says you need to phrase your stories in this way (and when you are capturing new stories, you probably want to just jot down a couple keywords, and write the story in long form later), it is important to be aware of the relationship between the “so that…” part and UX.  Looking at our earlier example with our substitute teacher Becky, the “so that” reveals the Why of the story.  It reveals both the motivation behind the story and often also can reveal something about the context. However, when trying to get a lot of stories created in a short amount of time, this part is often skipped.  And that’s understandable.  However, it is important to then be sure to go back at a later point and get your “so thats.”

To understand why, let’s look at an example where the “so that” is missing.

Hmm, why would searching visually be so important?  In a later conversation with an auto mechanic, he explains:  ”I want to be able to search visually, so that I can find and visually match the part in the search results to the physical part as well as see in the search where in the engine or vehicle the part should be located, to make sure I am ordering the right part.”  Wow, the “so that” part suddenly revealed a desire for a completely custom visual search interface and a desire to be able to search while working on the car, meaning maybe searching with greasy hands and lying on your back. Seriously valuable intel.  Make sure you get those “so that’s” people!

5. Don’t confuse Story Maps with User Interface

While a story wall provides a good overview of the product, it is much harder to evaluate for completeness compared to a user interface.

Story mapping is a powerful way for managing stories and offering a big-picture view of the product.  But it is also a far more abstract view of the product compared to the corresponding user interface.  It is virtually impossible for a Product Owner or other domain expert to look at a story map and say, yup, looks like we’ve got all the stories there.  You have to actually flow through it in a user interface to see what is missing. In other words, after you’ve developed your story map and think you’ve got good story coverage, assume you’ll be uncovering a good chunk of new stories as part of designing the user interface.

Additionally, even though you may have organized your story cards into thoughtful silos that reflect the structure of your product or domain, that can easily be confused with an actual user flow, in which the reality is that users may be jumping around back and forth between your different silos, even if your silos have been organized in an order that generally matches your domain’s workflow.

Therefore, create stories maps and use them for all the reasons that they are powerful, but quickly start to generate user interface concepts based on the cards in the story map to uncover aspects of the product that stories, by themselves, often are not very good at revealing.

To be continued…

This post got to be pretty long, so I decided to break it up into two parts. Read part 2, in which I talk about other key factors UX designers should consider when working with Stories, such as story context, story coverage, and story estimation.

Together with members of the Agile Experience Design LinkedIn group, I created a survey on the State of Agile UX. The overarching goal of this survey was to begin to understand what is and what is not working when it comes to adoption of Agile among UX designers. The survey was inspired by Version One’s annual State of Agile survey, which have been surveying Agile adoption since 2004(?). Similarly, we wanted to establish a benchmark for what is likely to be an adoption that will continue (and evolve) over the years.

The survey was conducted between Oct. 16-24, 2010. We received 150 responses. We are still churning through the findings but I wanted to post some initial findings I thought were of interest. I am still working on a more detailed analysis of the data. If you have experience wrangling Excel (e.g. doing PivotTables) and doing survey analysis, pls do get in touch.

Survey Overview

• Total Participants: 150.
• 80 participants identified as being primarily UX Designers.
• Survey Goals:
  • To understand the level of success in integrating Agile and UX disciplines, and the reasons for the success or failure.
  • To establish a benchmark for future surveys.
• 18% described themselves as very successful
• 45% as somewhat successful.
• Only 5% described themselves as very unsuccessful.
• The written responses at the end provide some insights as to the reasons behind the success or lack thereof.
• We received a lot of suggestions for how future surveys could be improved, such as to focus less on web design, focus less on user interface design, or on UX as a role.

Findings in a Nutshell: Same as it Ever Was

The challenges with integrating Agile and UX are not too different from the obstacles one might encounter when integrating a traditional UX practice into a waterfall methodology. Any form of change will meet resistance, logic and reasoning be damned. I remember years ago having to fight tooth and nail to convince management of the value of doing user research and creating detailed wireframes and specifications. The digital world has changed significantly since then, with detailed specs being far less-cost-effective. But resistance to change is the same as it ever was. And integration of Agile and UX is no exception.

Among the reasons for failure, it was therefore not surprising to see cultural resistance at every level (organization, team, peers) as being the strongest pattern. Another major pattern appeared to be going through the motions of change (e.g. doing something for two weeks and calling it a sprint or stand up during meetings and calling it a Standup), but missing the critical underlying Agile thinking, also seemed a strong pattern among those who described themselves as not succeeding.

Not being co-located, i.e. being in the same physical space as other team members seemed to also be a major factor. At the same time, some replied that they were successful despite being physically separated, because they were in regular contact virtually. Another interesting stated reason for failure was that Agile developers seemed to not regard the UX design role or discipline as valuable or important. Remember, it is not just UX designers who are part of this change; the attitudes of developers and the team as a whole is an equally critical factor.

Among the reasons for success, they also seemed to be factors that would make any team successful, regardless of if they are adopting Agile or something else. Many respondents described team empowerment and autonomy as a major factor, i.e. teams that are able to decide how they want to work together and create their own process as they go. Another major pattern was developers seeing the value in UX, or the UX role straddling the developer-designer divide (e.g. a UX designer who also is a front-end dev) were a strong pattern among those who described themselves as successful.

These responses re. the reasons for success seemed to capture the essence of what many were saying:

“For our teams, the UX designer is a dedicated team member – reporting to their product teams. Complete integration with a development team creates a much more successful team dynamic, shared ownership, opportunities for learning and growth, etc, in comparison to having UX as an external team/department.

We have also abandoned the idea that you always should design a sprint ahead, always use certain design methods, etc… Over the years, we’ve learned that there’s not “one right way” to do design & development. Some problems need the extra time to experiment and iterate and others don’t. Some designs need prototypes first, some can be iterated on in tandem with development. We’ve become far more flexible in our approach and techniques, over the years. We learn as we go.” — Alan Dennis

“Everyone talks about how important it is to keep the UX design ahead of the development sprints. I’ve found that this often means that the UX designer is the first to encounter tricky architectural issues. So one thing I’ve learned is that the entire team needs participate in the evolution of the UX design for a given feature or new area. This means that the development team must devote some % of their hours in a given sprint toward reviewing UX design for a future sprint and you have to factor this into the schedules. But if done right, both the UE and any important architectural coding issues are well understood before the story is picked up for implementation. Doing so can help avoid unexpected surprises that cause churn in the UI, features or schedule.” — Robin Silberling

“The UX designer and the Web Develper are part of the sprint planning and we sit next to the back-end Developers. The back-end Developers are very interested in watching the videos of the usability tests. Also they find the wireframes and Agile Acceptance Tests usuful when coding up the windows. We have had quick meetings with the UX designer, Web Developer and the back-end Developer to clarify what needs to be completed before coding starts. All developers are encourage to ask questions and give feedback on the wireframes or any part of the design/coding process. Before introducing the Agile Accpetance Tests the Developers were asked what they thought and if they had any feedback.” — Anonymous

Looking at the Numbers

A key focus here is on activities and process. We–rightly so, in hindsight–got a lot of feedback that we were too process-focused with this survey and were looking at UX as a separate person rather than a literacy. We’ll be working to correct that in future surveys. With that in mind, these were some findings relating to how UX is integrated into Agile teams.

UX-Designer Co-Located with Developers
Nearly 50% of respondents said that the UX designer is co-located with developers all the time. Once we start filtering findings, we’ll check this against those which identified as finding their agile adoption a success.

UX-Designer Doing Front-End Development
50% of respondents identified the UX designer as either regularly (20%) or occasionally (30%) also doing front-end development. Cross-disciplinary roles, i.e. team members wearing many hats is a strong indicator of successful/healthy team (see written responses below.)

Designing Using the Production Technology
45% said they regularly design directly in the browser and only 14% said they had no idea what that meant. If a team is designing in the browser, this is a strong indication that they have a tight integration between UX and dev practices.

The Last Artifact Created Before Development Begins
Detailed wireframes and functional specs continue to hold the lead, with 43% using this as what is the basis for initial development work, with hi-fi prototypes a close second at 33% percent. Only 15% go directly from sketches and whiteboarding to development. This is an area where there still is a lot of room for improvement. In my experience, UX designers continue to struggle with letting go of the deliverables mentality, the idea of UX being one of creating pretty-looking design artifacts before starting to create software.

When Does Detailed Design Work Occur Relative to Development?
Only 8% complete all detailed design work before any development work begins. 50% complete a majority before development. 35% are doing detailed design work in tandem with development. Here again, there is plenty of room for improvement. The idea of not designing everything in atomic detail before starting to build can seem scary to a traditional UX designer. There are probably also a lot of business/org culture/peer pressure factors here that will drive UX practitioners to feel compelled to create all this detailed design up-front.

More Written Responses

Reasons for Success

“UX designer is respected, full member of the team”

“We’re somewhat successful because I think previously we were working with high-fidelity mockups that made it hard to iterate in tandem with developers and design and implement an UX in an iteration or two. We’re now more focused on paper prototyping to give developers the guidance they need around implementing functionality, and designing more directly within the browser within the current iteration. This has been working better, but I think it’s taken a long time to get the hang of UX tools and methods that match the speed of development and iterative methods.”

“We explored the potential of every person & helped other person learn something new. In short we recognized the capability of the team. Made sure who the actual owner of the Story is & made others contribute in the mix. In short, we empowered the team to make decision & requested management solve the impediments & stay out of teams face.”

“The Tech lead is a huge supporter of UX and understands the value. And, if he ‘forgets’ about me at times, he does what needs to be done to get me integrated back in the dev cycle.”

“…the UX desinger has always been considered part of the team. I used to be a FE dev so understand the complexities. Am also a ScrumMaster and attended the training with the developers. Started from the same point. This means I’ve always had very good relationships & high levels of trust with the devs. Always get dev feedback on feasibility and we can all be part of the process.”

“Even though we’re geographically dispersed, we are constantly in touch via an ever-present group skype chat.”

Reasons for Lack of Success

“We have off-shore team, hence bringing them up-to-speed & style is getting challenging. Team here in US still has the mentality that US team is the best.”

“Too many executive stakeholders who don’t understand the value of agile methods. UX team (our client) still focused on producing deliverables rather than working code (site maps, content inventories, requirements, specs)”

“The organization started pure agile and is struggling to integrate ux”

“My organization still views agile and ux as diametrically opposed interests. They still view ux as an upfront activity. My local project teams have a changing view because of their experience working with me, and I hope that view spreads throughout the organization.”

“Front end developers requiring more design detail thus pushing more work onto design.”

http://webtorque.org/?p=1060

“We don’t involve users. We create interfaces that are very flashy, but not terribly useful to the user.”

“The lack of co-location and general “design” think is the biggest barrier.”

Imagine yourself walking down a fictional hall in a fictional office building and passing two different offices.  In the first office sits a UX designer, busily plugging away at a deck of wireframes, preparing to review them with the rest of the team.  In the second office sits another UX designer, also busily plugging away at a deck of wireframes, preparing to review them with the rest of the team. At the surface level, these practitioners appear identical.  And yet, they are worlds apart.
The first designer, as he is working on his wireframes, thinks of them as a clear representation of the user experiene layer of the final product.  He is expecting to present them to the development team and then for the development team to build the UX layer, mostly according to the design, perhaps with a few minor tweaks down the road.

The second designer thinks of his wireframes merely as a starting point for the design of the actual product.  He sees them more as sketches rather than specifications.  If developers were to respond simply with a “looks good” to his work, he would be worried indeed. He intentionally only a spent a minimum of time working away from the rest of the team, quickly generating a few UI concepts, and is now expecting to collaborate with the team to evolve them.

These two designers represent the essence of what sets a traditional waterfall approach apart from an Agile approach.  If you think being Agile is about doing daily Scrums and Standups and doing Story Mapping and Retrospectives, think again. They are nothing more than tools. Going through the motions of these activities without understanding the thinking behind them is like speaking a language without knowing what the words mean.

No, the true power of Agile is not knowing Agile activities inside and out or being able to recite the Agile Manifesto by heart. The true power is in understanding the underlying thinking, the attitude toward software that fueled their creation. And at the end of the day, as Jim Highsmith and others have said, Agile is no more than an attitude, a mindset. In fact, you are likely to find greater success when starting out with Agile by ignoring the well-known Agile activities and principles and to continue working the way you currently work, and focusing instead on only one change: your attitude.  That shift, in turn, will drive change from within your current practice, rather than attempt to impose it from the outside with some activities you read about in a book.

So how can one develop an Agile attitude?

First, let’s be very clear, changing your attitude when it comes to adopting Agile is about changing your habits, changing your mindset, changing what you see as a Normal way of working.  And that is unlikely to happen overnight. In fact, that first designer at the beginning of this post is me about ten years ago and the second designer is me today.  Now, that’s not to say it will take a decade to change your attitude. In fact, among the many changes, here is one central change that I made and which worked for me.  More importantly, it is something you can start to put into place now

Stop Designing Alone

For a number of reasons, many UX designers are strongly conditioned to design alone.  This unfortunate yet common pattern is perhaps the single greatest obstacle in allowing for developing an Agile attitude.  Among its many detriments is that it perpetuates an Us/Them mindset and that it makes ritual-free rapid communication, a cornerstone of Agile, nearly impossible.

A common working-alone pattern is to first gather information from team members and stakeholders, and maybe do a bit of whiteboarding with the team, and then go off and create the “real” design in your cubicle with your headphones on.

Designing is a process of making innumerable micro-choices, and as software systems become more complex, each choice needs to be looked at from multiple dimensions.  When you are working alone with your headphones on, you are making one-dimensional decisions: yours. Perhaps you spent hours and hours designing a custom UI solution, only to learn that an off-the-shelf solution already exists. Perhaps you made some technological assumptions about what is and is not technially possible, only to learn that something you assumed not possible in fact is possible or vice versa.

Yes, focusing on a problem alone can have value, but usually only in brief spurts.  Hours and hours of alone time is almost guaranteed to equal an increasing percentage of waste. So how do we stop designing alone and start designing together?  Two inter-related patterns for addressing this are Cross-Functional Pairing, which I’ve talked about before (and others have as well), and Active Collaboration.

Collaborate Actively, Not Passively

How many times have you presented a UI concept to team members, in which they are all sitting around a conference table, leaning back in their chairs, occasionally nodding in acknowledgment of your ideas? How many times have you then had them much later raise an issue about the UI that you in fact had discussed during that meeting? Why does that happen?  A huge reason is because they are only passively engaged, which in turn is largely caused by how teams traditionally collaborate, through stale old (and as 37 Signals would put it “toxic) meetings. The attitude is that you were off alone designing this thing, so its your design, not theirs, and now they are taking a passive audience stance, only half-listening, only half-participating.  If you want true participation, you need active collaboration.  And that can be powerfully enabled by implementing a few ground rules:

• Stop talking about meetings and start talking about workshops.
• Commit to delivering the real high-level design concept during the meeting. This means actually creating the real design documents as a team, not having you create it afterwards.
• Commit to creating living documents, i.e. those that everyone can see and participate in creating.
• Commit to doing detailed design in pairs, not individually.

This will be hard at first for traditional teams, but stick with it.  A fundamental shift will be in the types of artifacts you produce.  You will go from creating document-centered artifacts (i.e. those in which the document is expected to contain the primary information) which are time-consuming and anti-agile, to conversation-centered artifacts (i.e. those in which documents are designed only to support conversations, which are the primary conveyors of information), which can be created and updated in the moment. Over time, you’ll start to see a change in how your team works together, and a change in attitude, toward one another and toward the design of the software as a whole.

One of the most consistent patterns I see among those integrating UX and Agile is a business-as-usual approach to Personas, i.e. continuing to create them largely in the same way as in a traditional waterfall practice.  Doing so, in my opinion, is a mistake, and reflects a lack of understanding both of the purpose behind Personas and the thinking underlying an Agile practice.

Personas are research artifacts based on real people and real research data that humanize and capture key attributes about archetypal users.  What are their goals?  Preferences?  How do they work? And so on.  They serve both to inform design decisions and, maybe even more importantly, increase designer empathy.  In other words, they are a reminder that these are real people.

So what’s wrong with that?  From a user experience design perspective, what could be more important than to understand your users?  Yes, that is all good and well. The problem with Personas is that they can become an excuse to not work face-to-face with real users.  In a traditional waterfall model, Personas effectively function as a surrogate for being able to interact with flesh-and-blood humans while designing the product. The expectation is that you will spend the majority of your time away from the real users and therefore need something to evoke who they are, so that you don’t fall into the trap designing who you imagine the user to be and not who the user is, or worse, end up designing for yourself. (And don’t get me started on designers who create “Personas” out of thin air based on imaginary users rather from actual research data. At that point, you may be creating a nice reminder that you’re designing for real people, but the persona itself is basically useless or even misleading.)

But in an Agile model, you should be in regular contact with the actual people for which Personas are intended to serve as surrogates.  That means that your approach to creating Personas should shift significantly from how they might be approached in a traditional model.  Depending on how frequently you are in direct contact with actual users, the persona can be correspondingly light-weight.  In other words, if you meet with users every day or every few days, a light-weight persona can contain as little as the person’s first name, a picture of the person in the actual environment in which they will be using the product, and a few bullets re. goals, motivations, and perhaps a “money quote.”  But that’s it.  Anything longer or more detailed, such as this very polished Persona and you’re back in waterfall world, spending more time on designing documents than designing software.

Btw, the name of the persona should be a real name and just a first name, for two reasons.  Referring to someone only by their first name is both more intimate, and also provides that person with a bit of privacy to those outside the project who may see a persona posted on an information wall. Additionally, by having a real name, the name itself becomes a shorthand for the persona, since all you need to do is say their name during team meetings and team members, who in an Agile model all will have met this person, will have a clear image of the persona you are referring to.  In other words, in an Agile model, Personas are…real people!

Being able to glance up at a persona on your information wall to remind you of that real person can be valuable.  A possible downside is that you may end up designing for only the people you are working with and not the archetypal user, but that can be mitigated in a number of ways, such as ensuring that you have a regular cadence of a wide range of users interacting with the working software.

Furthermore, traditional Personas are also based on a sampling of the overall demographic.  And since they often only are created once, as part of a discovery phase, they are effectively a freeze-frame of a real person. But real people are quirky and weird and often inconsistent in their behavior and maybe you caught them on bad day or whatever during the discovery phase.  By working the actual people over time, you get a more normalized version of a traditional persona, one that reflects all of people’s normal fluctuations in character and temperament over time.  An Agile Persona, in other words, can be easily updated throughout the project as you continue to discover new things about your users.

Yes, sometimes you will not have the ability to work face-to-face with actual users, but in those cases I have found lots and lot of pictures of a wide range of users in their normal environment to be far more valuable than text-heavy Personae.  (And I just had to throw that ultra-nerdy plural usage in there at the end…)

This last weekend, a group of about 30 UX designers, developers, and leading thinkers in the Agile UX space (Jeff Patton, Ward Cunningham, Alan Cooper, Lane Halley, Desiree Sy, and William Pietri among others) met at Cooper in San Francisco to talk about the power and the challenges of integrating the Agile and UX disciplines.

Photos by Chris Nodder.

Not surprisingly, there were a wide range of opinions.  More surprisingly, for such a large group, we were able to keep our discussion focused and productive.  These are some of the big take-aways that stood out in my mind.

The Us/Them Challenge

We intentionally had attendees with a mix of backgrounds, including UX designers, developers, testers, and managers.  A consistent theme throughout the event was that of the Us/Them challenge, of how the separation of work among team members is a fundamentally negative force working against the project’s chances of success, and goes to the core of why traditional waterfall methods so commonly fail.  That separation, be it via role-based silos, throwing work over fences created by phases of work, or the underlying mentality that What I Do Is Different From What You Do, is the source of the Us/Them camps within teams and the havoc they create.  Agile, in contrast, seeks to minimize the Them and maximize the Us, not just through focusing on distributed knowledge, but also on distributed understanding and empathy for other team members.

We tussled over the issue of how much work UX designers should be doing on their own, how much work they should be doing up front before involving developers, and ended up rallying around the cause of the barely sufficient Iteration Zero, of doing the absolute minimum separately from other team members throughout the project.  And when Us/Them thinking would creep into our discussion, such as when a UX designer started talking about the importance of alone time, someone else would call out “Us/Them, Us/Them!” as a kind of mantra of the event.

What is the relationship between UX and the Agile team?

We had a lot of interesting discussion re. where UX fits into, or what its relationship is, to the Agile team.  The idea that UX should be more a competency and less a role resonated strongly. Alan likened the software team to a sports team on a field, in which everyone has set roles but their actual work can be fluid across the field/project. We also discussed the role of the UX Developer, a prototyping competency dedicated specifically to simulating User Experience, as a powerful pattern in Agile UX – at least two of those attending were from organizations that had independently adopted this practice.

Toward a Post-Agile Paradigm

But perhaps the most interesting take-away from this event was that there was a strong feeling among us that we are moving toward (or have already entered) a Post-Agile Paradigm, meaning that what we really are talking about here is not the Agile your grandparents knew and loved, er, I mean the Agile which the original signatories (of which one of them, Ward, was attending) articulated in 2001.  Remember, Agile in its original form is largely silent about UX.  Our conversation was about a paradigm in which the voice of UX plays an equal role in the project chorus.

Here are a some nugget quotes from the event:

Proccesses that are able to embrace the unexpected will look sloppy to the outsider. -Ward Cunningham

The only products that are really done are the ones that die. - Jeff Patton

If you work really hard to please your customer you will most likely fail. If you work really hard to please your user you will most likely succeed. -Alan Cooper

Iteration Zero is about paying down strategic debt. -Desiree Sy

Product ownership is a team effort. -[Don't recall who said that]

At the end of the event, Lane was leading us through a root-cause analysis, to help us drill down into specific causes and corresponding actions we might take.  We actually were not able to quite finish this exercise before we ran out of time, which sort of left us with a kind of cliff-hanger motivating us to organize a follow-on event, which I very much hope we can do in the near future.

Also, other attendees have posted links to their blog posts about the event at the Agile Experience Design social network.

Thanks to the following companies who made this event possible!

Atomic Object, Cooper, HP, Pivotal Labs, and TechSmith.

Designing a user experience is usually considered synonymous with the work of designing the part of a system users will directly interact with.  While that is all good and well, a general problem I see in the UX practice is that this then becomes the place where the UX work not only begins, but also where it ends.  In other words, the underlying functionality, the components that actually allow for the interaction being designed to function is either completely ignored or only given cursory consideration from a UX perspective.

This lack of attention to the impact of the non-visible aspects of a system on the user experience is, in my opinion, a major reason for a lot of bad user experiences.  If you think about it, if your page is slow to load, if you try typing into a text field but nothing happens, if some seemingly simple action in the UI in fact initiates connections to a bunch of data sources and causes whole interface to become sluggish, who cares how perfect your UI design is?

I think a lot of UX designers shrug their shoulders at issues like this.  Hey, that’s the developer’s problem not mine, right?  Yup, definitely the developer’s problem, just like the proverbial leak on his side of the boat is his problem and not yours.

The issue here is not one of who is responsible, rather one of an awareness that it may critically impact the user experience, and therefore the User Experience design process should be one that allows for surfacing the issue and addressing it.  Current conventional methods of UX design, i.e. focusing solely on the user interface first, then waiting to deal with pesky issues such as load time later is only likely to ensure that those issues get relegated to the revolving “Phase 2″ version of the application.  A better way to address this is to rethink the relationship between UX design and development, and a great example of that is to evolve the GUI in tandem with the software build.

An Agile UX Method: Functionality First, GUI Second

The idea of designing the user interface in tandem with the build is a good example of applying Agile thinking to UX.  Here, instead of first creating some fully formed interface concept before starting to actually implement it, we take a step back and look at what underlying functionality needs to be developed.  In cases where it makes sense, such as a piece of  functionality that may be simple at the user interface level  but where there may be some heavy lifting on the back end, rather than spend a lot of time at the outset trying to come up with the perfectly user-friendly UI, we instead abstract out what inputs the user will provide and what outputs the system must return and then create a minimal user interface, of which the most standard is the command line interface.

Example of a minimal user interface, showing only inputs and outputs

Here is an example of an auto parts search, in which we know that actually connecting to the various parts warehouses and then executing the search is going to be highly complex.  Therefore, before spending a bunch of time designing a GUI, which will need to make assumptions, for example, about the amount of time that will be required to complete a search, we instead start by building a first iteration of the search functionality and use a skeleton user interface.  With the knowledge of the actual average time of completing a search, as well as issues related to connecting to the warehouses, we are in a much better position to build a graphical user interface around this, in which we can clearly set user expectations, as well as determine much more effectively what forms of dynamic features in the UI we can support, such as how much flexibility we can allow for in terms of user inputs. (I.e. maybe we discover that Name needs to be a separate field from ID or whatever.)

This can be an incredibly powerful way of working, since it actively and organically involves developers into the design process, allowing you to collaborate much more closely in evolving the user interface.

As an independent consultant, I am able to work on a wide variety of projects, collaborating with highly diverse teams.  While I’ve worked with some incredibly talented people, I also see a pattern among UX professionals that is incredibly unfortunate, namely what I call the Reality Problem.  At it’s core, the problem is this:

Most UX Practitioners Never Actually Create Anything Real

By Real, I mean actual working software that you can do something with, that is neither a simulation or a prototype, but is in fact the gosh-darn real deal. When was the last time you actually wrote real working code? If your answer is “not long ago” then I applaud you, but I also lament the fact that you probably are in the minority within the UX discipline.

So why is this a big deal? Well, it is for several reasons…

If you’re not building stuff, you’re removed from reality

What if you were writing a book about gardening but had never actually dug your fingers into the dirt, never actually planted vegetables, never watered and nursed them and kept weeds from suffocating them, never felt the joy of seeing them take root and grow and bear fruit.  How could one possibly write a book about gardening without these real, tactile experiences?  It would obviously be impossible, right?  But designing software is in many ways no different from gardening, and to understand software, to know how to design it and get the most out of it, to have a blooming, thriving crop, as it were, well you’re going to have get your hands dirty.

So am I saying that all UX designers need to become software developers?  Absolutely not.  But what I am saying is that unless you regularly dig around in some code, you’re going to lose touch with the reality you’re designing for.  Additionally, you’re going to lose your empathy for the people you’re designing for.

If you’re not building stuff, you’ll have less empathy for those who do

No, by people I’m not talking about end users.  Yes, empathy for the end user is important, but that’s a completely different issue.  I’m talking about your actual target audience, which is not the end users. (They are the target audience of the product itself.)  The actual target audience of the work that you produce is the developers (and, depending on your team or project, other roles, such as visual designers.)

And believe me, if you’ve personally had to write production grade code, I can guarantee that it will impact how you approach your design solutions.  You will, for example, think twice about throwing in some gratuitously cool feature.  For the person with no coding experience, that little dynamic widget thing they dropped in their wireframe took them maybe all of 30 seconds to add.  In other words, there is a complete disconnect between their work and the reality associated with this feature. And that reality is that 30 seconds of UX work can equal a full day’s work for a developer.  Does that mean we should not innovate and continue pushing the envelope?  Of course not.  It simply means that one should be more pragmatic, and defer to the standard solution in most cases, and then innovate in places where you really can make a strong case for that it is worth the effort.

By simply having more of a general appreciation for what is involved in coding something, you can save yourself and your team so much of the time and headache that tends to go into back and forth of a developer having to explain to the UX Lead that, um, yeah, that thing you got in there is pretty darn complex.  Instead, you might be able to empower your design skills by thinking a bit more like a developer.

If you’re not building stuff, you’ll never understand how developers think

I remember many years ago toiling away at a deck of wireframes for a content management system, only to later discover that my detailed design ideas were largely being ignored by the developers.  Why?  Because after reviewing my wireframes, they had then taken a broader perspective on the problem, and decided to use an off-the-shelf CMS framework.  As it happened, that CMS framework came with a default user interface out of the box. In other words, my approach of focusing on the UI rather than on focusing on the design of the overall system led me to wasting a lot of time.

The developer perspective turned the whole UI design process on its head.  Instead of starting by designing a UI, it here was more effective to leverage an existing UI standard and then shift from a design exercise to a customization exercise of that UI.  While my mindset was fixated on creating a UI from scratch, they were all about reuse.  And why did they never mention this to me, allowing me to create a whole deck of virtually useless wireframes? Well, for the simple reason that I never asked.  If I had taken a developer perspective on my design, my starting point would instead have been to first work with developers to research what available frameworks are out there, and then if we agree on one to use as a starting point, my design exercise is instead transformed into a customization exercise.

Another great example of developer thinking is reflected in test-driven development.  In that model, a piece of code is the user requirement. In other words, instead of writing a traditonal list of text requirements, you instead make the underlying intent of that requirement manifest in the form of code.  In other words, since a well-formed requirement should be unambiguous and testable, why not represent it as an actual piece of code that inherently will be unambiguous and will simultaneously be what performs the test of the requirement that it describes?  This type of thinking can be really really hard for UX folks to understand.  But I think if they were to spend less time doing wireframes and more time actually building stuff, it would suddenly make a lot of sense, and the whole design effort would be better off because of it.

This last Thursday, we had the first NYC edition of the UX Book Club.  I attend a lot of UX-related events, but this one had a palpable energy and excitement that I haven’t seen in some time.  At the beginning of the event, some of us offered mini-reviews of our book choice, Bill Buxton’s Sketching the User Experience.  Peter March gave such an impassioned review, I kept expecting him to whip out a bible and start waving it.

And that sort of set the tone for the rest of the event: high-energy, engaged conversation, a fertile middle ground between events where there is a single speaker with everyone else semi-passively engaged, and free-for-all cocktail hours, which are fun and great for networking, but lighter on substance.

Now, with a couple days hindsight, I have both great hopes for the potential for where this budding movement might take us, but also a creeping fear, concern, trepidation, whatever, that we will only read the books we’re already talking about, only the books written by people in our midst, only the books matching a search for “User Experience.”  Our reading choice for the event, Sketching UX, is a great book, dare I say an important book in the UX canon. We should of course keep reading books like this, book club or no book club.

But if we only read Books Written By People Like Us, I fear the UX Book Clubs will become navel-gazing, inward-looking, gatherings, where we mostly are drawing on ideas coming from within our practice. One way to prevent that from happening is to mix up our book choices a bit, and also include voices at the edge (or outside) of our practice, which I think would enrich our practice by looking at it from the outside in.

These are two books I think exemplify that edge, that are written by authors at the edges or outside our practice, and books I would strongly recommend as a reading choice for the UX Book Club.

Drawing on the Right Side of the Brain, by Betty Edwards

Though it will teach you how to draw, this is less a book about drawing, and more a book about seeing and thinking about drawing and illustration.  Too often, the focus when talking about sketching and wireframes is on the what (nomenclature, hierarchy, flow, etc.), which of course is important.

But just as important is the how.  A brilliant design concept presented by way of a crappy-looking sketch or wireframe is likely to be far less persuasive than one produced by a skilled illustrator.  And I’m not talking about whether or not an early idea looks sketch-like to invite feedback. Even that, attention to fidelity, is part of the illustrator’s craft.

And that is what Edwards teaches in this fantastic work, not only how to draw, which is important, but how to make drawing something you just do without thinking, like riding a bike. In fact, I think this book should be required reading as part of the core curriculum in an Interaction Design program.

Crystal Clear, by Alistair Cockburn

Moving to the opposite edge of our practice, this is a book by one of the leading progressive thinkers in agile software development, and one of the original signatories of the Agile Manifesto.   In my opinion, it is one of the best books on the agile and iterative development methodology.

But more importantly, from the vantage point of a UX Book Club choice, it takes the developer’s vantage point: a crisp, unvarnished, and unforgiving take on what it means to design something that ultimately will need to take the form of ones and zeroes.  (Getting back on my what-should-be-in-a-ixd-curriculum-bandwagon, this is also a book that I think should be part of such a curriculum, but as part of an advanced course.)

Let’s not forget who are the ultimate users of our work.  After business stakeholders have hemmed and hawed about (often irrelevant) details on our wireframes and prototypes, after visual designers have enhanced and enriched our designs with elements both beautiful and beautifully useful (well, ideally anyway), the buck will ultimately stop with the technologists.   And Cockburn is one of the technologists and thinkers who is part of forging the path many many of the developers you likely work with or will work with are following.

These are just two books at the edge of UX.  For me, I would really enjoy attending a UX Book Club event discussing books like this, which I think will broaden and enrich our practice by helping us see our practice from the outside.