I really like user stories for higher-level stakeholders. Executives and business analysts approach the problem of product development from a different angle. The primary motive is “what can we build that will increase our revenue the most?” Now, thankfully, this dovetails with “what do our current users want?” and “what do potential customers want?” but it puts a particular lens on the problem. By focusing on a user story, which can be written quickly and understood at a high level, you can make a pretty good rough-cut at what you should build and what the business value should be.

Now in a pure Agile environment, this user story might have been sent straight to developers. Can you see the danger here? I’ve heard of Agile teams who want only one sentence of guidance before they start coding. If your developers are also UX experts, no problem. They can solve the user issue, design and develop a solution, and off you go.

So what did we do next? We prototyped. Using ProtoShare, our UX Guru prototyped an implementation hypothesis. It included facets of the issue that weren’t included in the original user story: If arbitrary groups are supported, how are they managed? Do users have their own groups or are they project-wide or account-wide? If someone is added to a group, what happens to all the artifacts that the group is subscribed to? Are groups just a way to select a bunch of users or do they have some independent existence?

Prototyping made these issues concrete. Instead of thinking up all the edge cases, the higher-level users could experience the prototype and would ask specific questions (e.g. “I want to do this, how do I do it?”). Now sometimes these questions fall outside of the original user story, but sometimes they don’t. In the end, we answered enough of these questions to take it to our end users.

So we ran some sessions with customers who had specifically asked for this feature. They had lots of users. During these sessions, the reaction was typically: “yeah, this is useful, but I really want it to do X, Y and Z.” Ultimately, once the users saw and experienced the feature, they were able to effectively judge the actual value of the feature to them.  What we realized is that the feature we were considering to be the top business priority was really a “nice to have” for a handful of larger customers.

You can see why the business stakeholders liked this feature at first: it met the needs of our largest customers. The thinking was that we want to keep them happy, and that by addressing this need we would be a better fit for other big customers. And there was nothing obvious that appeared to serve this end better.

So our UX team learned, through collaboration with the business stakeholders, what the value proposition was for this feature. The business stakeholders learned, through collaboration, that the feature was deeper, more complicated and had more profound implications than were obvious at first glance. And both business stakeholders and the UX team learned from customers that this really wasn’t going to help us sell any more product.

Missing from this story is our development team. They never got involved other than some initial feedback about the feasibility and technical difficulties of various proposals. They continued to work on the already prioritized and understood features.

If we had decided to go ahead and build this feature, there would have been additional collaboration all up and down the chain focusing on development implications. (There are frequently even more missed functionality discoveries once development starts. Having open lines of communication to clear these up quickly is important.) By the time implementation was complete, business, UX, developers and end users would all understand and confirm the value of the feature.

Ultimately, the decision was made not to add this functionality in the next sprint. The total elapsed time between the initial prioritization of the idea and its abandonment as top priority was 3 days. But what I really love about this process is that we actually significantly moved the ball forward on this feature. We didn’t drop the idea completely, we just adjusted its priority. And the knowledge and understanding of the problem didn’t disappear. The user story is still in our system and it is linked directly to prototypes that explore the problem, questions and comments by all stakeholders, decisions and resolutions that are recorded along with their reasoning.

Something else you’ll notice about this story is that for each step in the collaboration, there are defined roles: business analysts prioritize the user stories and communicate that to UX. UX investigates the stories and communicates those issues to business analysts. Part of UX’s investigation involves testing hypotheses with end users.

This process emphasizes my two touchstones for successful UX: user testing and validation, and creation of a shared understanding. One other feature of this method of collaboration is that you need to maintain structure and responsibility for the various stages of the collaboration. This is not free-form brainstorming. It’s adding collaboration to a defined process. Business analysts do their work, and then they are required to communicate it to UX. The communication is a two-way street, with the goal of creating shared understanding. UX pros do their work and communicate it to business analysts, end users and developers, again in a back-and-forth process that listens to feedback, gathers evidence and responds to it.

So here’s our overall development process: Defects and feature requests can enter our system from almost anywhere. Many come from customer service, responding directly to customer requests. Others come from sales, marketing or development. All of these defects and feature requests are added to our Agile tool. Feature requests are translated into the form of a user story, although at this point we just want it in the system, so we’re pretty loose with the criteria. What product management wants in these situations is to identify a comprehensible user need. There does not have to be any implementation path inferable from the user story.

Product Council

Once every two weeks, business stakeholders meet to process new items and to review the priority of the backlog. (This is our product council and it includes executives, customer support, marketing, UX and development representation.)

The outcome of this process is a prioritized backlog of user stories.

UX then takes the top story on this list (or more than one, depending), and prototypes, decomposes, and works to get a full understanding of this story. UX shares prototypes with the developers who will ultimately be responsible for implementing the solution to get their input and perspective. If the developers are in mid-sprint, this collaboration may just be with the manager, but typically responding to the prototypes is no more burdensome than responding to email. The original business stakeholders also have visibility into this process. They can see the prototypes, and the UX pro can pull them in at any time to view prototypes and ask for clarification.

The End User is there

End user testing is frequently part of this process too. For our team, end user testing usually happens after one or more iterations involving the internal team. The prototypes and feedback from executives, sales, customer service and developers, as well as end users, are all linked to the user story or stories in the backlog. When the product council reviews the backlog, they can take this information into account in deciding the priority of each of these features. After UX exploration, user stories might have their priorities dropped, or other stories might come in that are higher priorities, and UX will begin work on those items. In effect, UX goes through a series of 2-week sprints to elaborate and explore user stories.

How does UX know that they are done? Well, assuming that product management keeps the user story as top priority in the backlog given the newly developed prototypes and discussions, development tells them.

Developers, developers, developers

Developers package sprints based on the backlog. The backlog now includes user stories, prototypes and discussions about a feature. Developers have been involved in creating these artifacts (even if only for feedback), so they don’t get any surprises, and it creates a feeling of shared striving.

Our developers move the top priorities from the backlog into a sprint-ready bucket. If items haven’t been adequately explored, the questions or issues are raised to the UX team.

Sprints are then packaged from items in the sprint-ready bucket. In general, these sprints are highly efficient. The issues raised are clear, well thought through, vetted by end users, and developers are already familiar with the issues.

Seek feedback

But collaboration does not stop just because a user story is placed in a sprint. Just as UX could request feedback from developers on user stories in progress, now it’s development’s turn to seek feedback and clarification from UX. Developers always uncover issues not considered by business or UX, because the lens of implementation has many additional considerations. Our developers sometimes modify the existing prototypes, ask questions regarding existing prototypes, make new prototypes, prototype in code, or actually develop a solution, make it available through the nightly build, and then request feedback. End user testing can also occur on actual, potentially releasable code. One thing to note – if end user testing reveals something critical, it’s much more difficult (and expensive) to turn the ship at this point. The UX sprint is more agile than the Agile sprint.

I’ll admit, UX has a tough job, and it is really the fulcrum of communication. While it’s usually adequate for developers to give quick feedback during the UX phase, UX frequently has to dig back in during the sprint. They may have to adapt existing prototypes, create new proposed solutions, vet changes with end users, and vet changes with up-stream stakeholders. The goal for UX is to help developers minimize rework. It’s up to UX to choose the most efficient path to vet and clarify solutions, so that once the developer builds the feature, changes are minimized.

Here are the basic steps and the primary groups responsible.

Propose (everyone) → Prioritize (Business) ↔ Explore, Test, Validate (UX) ↔ Build, Test, Validate (Dev) ↔ QA (QA) → Deploy (Ops)

So is this Lean? In Jeff Gothelf’s article on Lean UX, he includes an image describing the Lean UX process. The basic steps outlined are “Concept → Prototype → Validate Internally → Test Externally → Learn from User Behavior → Iterate.”

Given this definition, I’m going to say yes, we’re Lean. What’s interesting is that our process involves both a shadow-sprint (a pre-development UX-only sprint), as well as embedded UX and development. What I like about the shadow-sprint is that you’re not constrained by the sprint timing and that you don’t suffer from a UX-Dev impedance mismatch (where UX and development tasks take significantly different amounts of time). What I don’t like about the shadow-sprint is that it is more difficult to keep developers engaged in the solution and to create the shared understanding that I’ve beaten to death in my articles. Embedded UX makes the shared understanding possible, but keeping everyone busy and working at the maximum velocity can be much tougher.

Are you Lean? Has your organization been trying to implement lean principles? What are you finding? What works and what doesn’t. I’d love to hear your experiences.

Our product team was reviewing the feature backlog to determine what should have top priority. We’d heard from many of our larger customers that they wanted Users and Groups to be supported by my company’s product, ProtoShare. There were user stories written for this: “As an editor I want to be able to easily hide/expose content to arbitrary groups of users so that I can control their experience” – which was the main story that we wanted to tackle.

I really like user stories for higher-level stakeholders. Executives and business analysts approach the problem of product development from a different angle. The primary motive is “what can we build that will increase our revenue the most?” Now, thankfully, this dovetails with “what do our current users want?” and “what do potential customers want?” but it puts a particular lens on the problem. By focusing on a user story, which can be written quickly and understood at a high level, you can make a pretty good rough-cut at what you should build and what the business value should be.

Now in a pure Agile environment, this user story might have been sent straight to developers. Can you see the danger here? I’ve heard of Agile teams who want only one sentence of guidance before they start coding. If your developers are also UX experts, no problem. They can solve the user issue, design and develop a solution, and off you go.

So what did we do next? We prototyped. Using ProtoShare, our UX Guru prototyped an implementation hypothesis. It included facets of the issue that weren’t included in the original user story: If arbitrary groups are supported, how are they managed? Do users have their own groups or are they project-wide or account-wide? If someone is added to a group, what happens to all the artifacts that the group is subscribed to? Are groups just a way to select a bunch of users or do they have some independent existence?

Prototyping made these issues concrete. Instead of thinking up all the edge cases, the higher-level users could experience the prototype and would ask specific questions (e.g. “I want to do this, how do I do it?”). Now sometimes these questions fall outside of the original user story, but sometimes they don’t. In the end, we answered enough of these questions to take it to our end users.

So we ran some sessions with customers who had specifically asked for this feature. They had lots of users. During these sessions, the reaction was typically: “yeah, this is useful, but I really want it to do X, Y and Z.” Ultimately, once the users saw and experienced the feature, they were able to effectively judge the actual value of the feature to them.  What we realized is that the feature we were considering to be the top business priority was really a “nice to have” for a handful of larger customers.

You can see why the business stakeholders liked this feature at first: it met the needs of our largest customers. The thinking was that we want to keep them happy, and that by addressing this need we would be a better fit for other big customers. And there was nothing obvious that appeared to serve this end better.

So our UX team learned, through collaboration with the business stakeholders, what the value proposition was for this feature. The business stakeholders learned, through collaboration, that the feature was deeper, more complicated and had more profound implications than were obvious at first glance. And both business stakeholders and the UX team learned from customers that this really wasn’t going to help us sell any more product.

Missing from this story is our development team. They never got involved other than some initial feedback about the feasibility and technical difficulties of various proposals. They continued to work on the already prioritized and understood features.

If we had decided to go ahead and build this feature, there would have been additional collaboration all up and down the chain focusing on development implications. (There are frequently even more missed functionality discoveries once development starts. Having open lines of communication to clear these up quickly is important.) By the time implementation was complete, business, UX, developers and end users would all understand and confirm the value of the feature.

Ultimately, the decision was made not to add this functionality in the next sprint. The total elapsed time between the initial prioritization of the idea and its abandonment as top priority was 3 days. But what I really love about this process is that we actually significantly moved the ball forward on this feature. We didn’t drop the idea completely, we just adjusted its priority. And the knowledge and understanding of the problem didn’t disappear. The user story is still in our system and it is linked directly to prototypes that explore the problem, questions and comments by all stakeholders, decisions and resolutions that are recorded along with their reasoning.

Something else you’ll notice about this story is that for each step in the collaboration, there are defined roles: business analysts prioritize the user stories and communicate that to UX. UX investigates the stories and communicates those issues to business analysts. Part of UX’s investigation involves testing hypotheses with end users.

This process emphasizes my two touchstones for successful UX: user testing and validation, and creation of a shared understanding. One other feature of this method of collaboration is that you need to maintain structure and responsibility for the various stages of the collaboration. This is not free-form brainstorming. It’s adding collaboration to a defined process. Business analysts do their work, and then they are required to communicate it to UX. The communication is a two-way street, with the goal of creating shared understanding. UX pros do their work and communicate it to business analysts, end users and developers, again in a back-and-forth process that listens to feedback, gathers evidence and responds to it.

This presented a slight problem, as I’m all about collaboration. I am CTO at Site9, and our product, ProtoShare, is built on the premise that collaboration is a powerful process that will revolutionize your UX, design and development experiences.

And as I read the article, I found myself agreeing with much of it. Who hasn’t had the experience of seeing their ideas butchered by a committee? ( See ‘Why Design by Commitee Should Die‘ and ‘Team Collaboration: Identifying the Warning Signs of Failure & Getting to Success‘)

Brainstorming, in particular, is singled out in the article, and for good reason. The author states: “People in groups tend to sit back and let others do the work; they instinctively mimic others’ opinions and lose sight of their own; and, often succumb to peer pressure.” I really agree with these statements. This is why meetings can be so unproductive or worse. ( See also ‘Meetings Where Work Goes to Die‘ and ‘Making Meetings Productive‘).

Another point in the article I completely agree with is that privacy and solitude improve creativity and productivity. I love working alone. Some of my most inspired moments come from ruminating, researching, experimenting and working alone.

I believe in collaborative methods

And yet, I’m still a strident advocate for collaborative methods. I see collaboration as an incredible breakthrough that radically increases productivity. The first time I used a Google Doc spreadsheet, I thought “Here is a somewhat clunky, slower, less powerful version of Excel. But I love it!” Why did I love it? Because I could invite the board chairman in to look at and work on the spreadsheet. I could send it to all my board members and executives when I was finished to get their feedback, all in one place.

So I love collaboration. The key difference is what kind of collaboration. Sometimes I want to collaborate because I’m feeling lazy and I want someone else to do the work. “Brainstorming,” defined as: get a bunch of people in a room to spit out the first thing that comes to mind, might count as collaboration, but its not where you’ll get your massive productivity gains. My version of collaboration does not result in the collaborators getting out of the hard work of thinking, stewing, experimenting and generally making an effort. If you know anything about diffusion of responsibility, you’ll understand why collaboration can have negative effects.

So what do I mean by collaboration? To me it means getting other people to look at, understand and engage with what I’ve done (or engage with something someone else has done). When I’ve written a draft, come up with a solution or solved a problem, that’s when I want to harness the power of collaboration. “Here’s my idea — what am I missing?” People have an amazing ability to see issues that I missed, or even ignored, and to force me back to look at my work with fresh eyes. And what’s more, when I propose something concrete, the people giving feedback are more engaged and creative. That’s why collaborative prototyping is such a powerful means of collaboration. By definition I am presenting something visual and concrete. It’s easy for a huge range of stakeholders to engage with a prototype.

The beginning is important

I tell everyone presenting ideas in meetings to start with: “Here is what I am proposing and why I think it will work,” and then to ask for feedback. Compare this to going into a meeting saying: “I want to accomplish X. Does anyone have any ideas on how we could do this?” For me, the difference is stark. When I present a concrete solution, people get engaged. They can quickly sense the contours of the problem. They pick up subtle information based on my approach and reasoning. And they will see things that I missed.

One example of this, something that happened to me a few weeks ago, involved a product feature that had been on our roadmap for a long time. The implementation path was unclear. The feature had the potential to spiral out of control into an endless list of features. I’d done some thinking, and I thought that I had a strategy for an easy-to-implement, lightweight solution that would provide at least some progress toward solving the underlying problem.

I created a prototype to illustrate these ideas, and I presented them to the CEO and the engineers in charge of implementing a solution. There was pushback. (Have you ever had a conversation with engineers without pushback?) The solution wasn’t complete enough. It didn’t satisfy this use case or that use case. Yes, I said, but my solution is doable. It accomplishes objective A, even if it doesn’t solve B, C and D. It gets us moving toward a solution.

The meeting concluded that the engineers would spend a little time thinking about my solution and possible modifications. I would complete the task of fleshing out the user stories and prototypes so that my idea would be concrete enough to develop.

So…progress made, right? I didn’t love my solution, but it made progress. It was the best I could come up with, and it was a solid idea.

The next day, one of the engineers approached me to discuss the issue. He’d taken my idea, and it had spurred him to think of a slightly modified approach. It would require a small amount of engineering, but it would get us B, C and D. In addition, the benefit of this small shift would also spill over into several other areas of the application as well as open many interesting future possibilities. In short, his idea was perfect and brilliant.

Would either of us have gotten there on our own? I doubt that I would have. He might have, but the fact that I did some hard work and private thinking provided a scaffolding for him to use to complete his ideas.

This is the power of collaboration that I see over and over again. An individual makes the effort to solve a problem. This is a private process. The results are concrete. This is why collaborative prototyping is so powerful, in my opinion. The prototype makes the ideas concrete. This gets your stakeholders more engaged and requires more structured thinking and effort on the part of the individual before collaboration happens.

Brainstorming is great too

In fact, I think brainstorming is a great idea too. But not brainstorming as in getting people together to contemplate a solution to a novel question. For me brainstorming means: “I know you’ve all thought a lot about this particular issue. I want you to share your ideas in a nonjudgmental setting.” It’s the preparation that matters. When people collaborate on ideas that they care about, that they’ve spent mental energy contemplating, and that they understand, the results are phenomenal.

I did some research for an article about creativity. Part of the research was looking at models that academics use to model creativity. One thing they all had in common: preparation. You have to plow the field before you plant. The term we use is engagement: have I spent time understanding the issues? And I will state, unequivocally, that engagement is something only an individual can do.

UX is all about communication

Collaboration in UX is more important than in other fields. Why? UX is all about communication. The dangers of insular thinking in UX are that other people can’t relate to our ideas, even if they are good. When people say “an engineer designed this,” it’s not because engineers are stupid or haven’t thought the problem through. It’s because their values (consistency, supportability, development costs) are not the same as the values of the user (easy, intuitive, powerful).

Another feature of UX design is that I’m almost always working on solving someone else’s problem. When we build software, it has to satisfy the customers’ needs and wants. If I don’t bring them in on it, I can spin off endlessly. Feedback allows me to make course corrections instead of starting over. If I’m implementing someone else’s vision, I still need to work in solitude, but collaboration becomes even more vital.

The aforementioned New York Times article does say the following about electronic collaboration: “The one important exception to this dismal record is electronic brainstorming, where large groups outperform individuals; and the larger the group the better. The protection of the screen mitigates many problems of group work.” I agree with the point that the screen shields individuals from some of the drawbacks of social behaviors. But I also think that most internet collaboration requires an individual to be the driver (at least initially), to do the hard creative work that gets the ball rolling. Collaboration allows you to pass the baton between players, cross-pollinate ideas, stimulate thinking and get multiple points of view. Still, progress is made by individuals. Individual progress is improved with collaboration by engaged stakeholders at the right times. (See ‘Lean UX: Getting Out of the Deliverables Business‘ and ‘Our Blind Spot: Creating a Shared Vision‘.)

Inter

• You don’t work in the same building;
• You don’t meet as part of your regular cadence;
• Passing things off feels like “throwing them over the wall;”
• Your role is complete before their role starts (or vice-versa).

Intra

• You see each other regularly;
• You have regular meetings;
• Your work on a project has significant or complete overlap;
• You’re available for questions while they’re working and vice-versa.

These are really two ends of a continuum. But the closer your organization is to inter-team, the more challenges you’ll have with collaboration and creating a shared understanding of development efforts.

I’m going to assert that the main reason that inter-team communication is a challenge is that it’s really hard to create a shared understanding of a project when your only opportunity to do so is in some petrified artifact that you hand off to another team. But there are easy ways to improve this situation.

The main focus needs to be on opening lines of communication. Even if you’re just going to pass a giant spec doc off to your offshore developers, you can find a way to let them see your thinking behind the document. There are lots of collaborative tools for sharing information. Even a simple wiki can help fill the gap. Have your discussions, and document decisions out in the open. Understanding why a decision was made can be just as important as understanding what the decision was (e.g. “we used this layout to minimize clicks because this is the most important function of the site”).

Open up that line of communication to all the teams. What if a question comes up during development that wasn’t documented in the planning stage? As a developer, I can tell you this happens often. Some functionality is implied by the design, but it’s not specified (e.g. “if you want users to be able to customize this palette, you will have to build a separate management function for the palette”). Ideally I’ve been involved early enough to head off this issue. If not, I need a way to communicate it to the right people. Other trade-offs show up during development that need to be cleared with business users (e.g. “this solution will take 6 months to build, this one will take 2”).

Waterfall and the giant spec doc have been pilloried for good reason. The first reason is that no one gets engaged with a spec doc. The second is that for any project of significant complexity, the spec doc will be incomplete. And finally, spec docs don’t communicate the essential questions of the project: why are we doing this? Why did we make this decision instead of another? In short, you can’t create a shared understanding with a spec doc. You can create a shared understanding in addition to a spec doc.

So when you have inter-team collaboration, creating a shared understanding is more challenging. But if you’re aware that shared understanding is the most important output of the planning process, you can improve your work product. Even a brutally long spec doc is more comprehensible if I have the shared understanding created through prototypes, sketches, discussions and presentations. Any development process can be improved by making shared understanding an explicit goal.

You can see immediately why shared understanding is different from a BDUF spec document. Spec documents are focused on what will be built and how it will be built.

Let’s examine how shared understanding might work in practice. End users request feature X. Business stakeholders agree that customer acquisition and renewal will be higher if feature X is implemented. Sales validates that the lack of feature X has killed deals. These stakeholders may even have an idea of what an implementation should look like. (“Just move this over here and add a menu.”) All of these stakeholders think they understand this feature. Yet they almost certainly do not share the same understanding, and whatever understanding they do have is probably fairly shallow.

UX needs to process this input and come up with a user experience hypothesis for implementing the feature. The UX team then needs to communicate this back to the business stakeholders to make sure it meets their needs and to test the hypothesis with end users. You can use any appropriate artifact for this communication and testing: sketches, prototypes, written documentation, code, Photoshop or Play-Doh. The key is that you can effectively communicate your idea. (I prefer interactive prototypes for reasons I’ll discuss below.)

Once you have a design hypothesis, with whom do you share it? In an ideal situation, everyone. The first group I would bring on board would be engineering. They can tell you if it’s feasible, consistent, difficult, whether there are alternative solutions that would require less effort. In addition to the valuable feedback you’ll get from developers, this is also your opportunity to help them understand what’s being proposed and why it’s important. This understanding will help them during development.

After engineering, run your proposed solution by the business stakeholders, or at least a representative or proxy for the business stakeholders. After all, if your solution doesn’t solve their problem, there isn’t much use testing it with end users.

Then you go to end users. If they validate your hypothesis, you can then create whatever formal artifacts you need to get the feature implemented – user stories, wireframes, prototypes, or more formal documentation. My preferred artifacts for passing user stories off to development are user stories with associated prototypes. If you’ve been collaborating with engineering on the development of the prototypes, you’re halfway home. You’re creating documentation solely for the purpose of communicating to your developers and other stakeholders.

Interactive prototypes are the best way to communicate your design hypothesis to all parties. Sketches work well for some processes, such as when you’re in the same room discussing them. But there is one key ingredient to effective collaboration that makes prototypes the best option: engagement. You have to get your stakeholders engaged.

One of the problems we always run into with BDUF spec docs is that key stakeholders don’t engage with them. Yes, they’ll sign off, but let’s face it, no one can understand them. People like to play, experience, react. In terms of getting engagement, your best option is actual working software. Next is an interactive prototype, next is design comps, then wireframes, then sketches, with written documentation bringing up the rear. Here’s the thing though: just because written documentation is the least engaging doesn’t mean you’ll never use it. All of these techniques have a place. I find that prototyping has the right payoff most often – significantly faster than working software, significantly more engaging than other visual artifacts. (You might expect me to say that since at ProtoShare we build prototyping software, but try it for yourself, and you’ll find the right balance among the tools in your toolset.)

Shared understanding of what you’re building and why is a simple concept. It’s part of the power of Lean UX and Agile development. While shared understanding is more baked into these methodologies, it’s a pretty simple principle that you can use in virtually any organization to improve your development efforts. Find ways to keep your stakeholders engaged. Share information early. Listen to feedback.

———–

Thumbnail image CC by Kris Hoet