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 <link to shared understanding article>. 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.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.