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.

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…)

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.

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.

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.

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.