<p>Published on <a href="https://blog.prototypr.io/agile-ux-what-i-learned-from-living-with-an-agile-developer-4173a60a8172?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Dana Solano </p>
<p>As a User Experience (UX) Designer, I know first-hand that it can seem like a challenge to bring UX design and Agile development together — Agile encourages the breakdown of work into small, independent, and incremental changes while UX design emphasizes the need to conduct research to understand users and what they need to address an experience from start to finish. Two years of living with an agile developer has given me an opportunity to bounce around ideas about tighter integration between Agile developers and UX designers.</p>
<p>When I was first asked to work on an Agile project team, I read up on the <a href="http://agilemanifesto.org/principles.html">principles behind the Agile Manifesto</a> and was happy to see the very first principle stated as: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” I was optimistic that any process supporting the frequent feedback on a product from real users would result in a better user experience. However, as I got into the day-to-day implementation of Agile on a real project, it wasn’t long before I felt I was on the sidelines of a “developer-centric” process where the users’ needs weren’t a central focus.</p>
<p>Frustrated, I started taking my complaints home to the Agile developer I lived with, Jack. And when I did, he not only had insight into why developers might be reacting the way they did to my requests, he had his own issues with UX designers that may not have otherwise occurred to me. So what started as standard, dinner conversation complaints and comments about work turned into honest conversations about why there was conflict and how we might be able to change our deliverables and processes to improve working relationships between developers and UX designers in Agile environments.</p>
<h3>The Problems</h3>
<h4>My complaint: “Developers don’t seem to care about the users at all. And getting them to watch a usability session… forget about it.”</h4>
<p>Jack assured me that it wasn’t a lack of empathy that was causing this refusal, it had to do with the way the developers and their progress was measured. Developers would estimate the complexity of tickets in points, and their velocity was measured (the number of points completed in a certain interval) and used for planning and work tracking efforts. Asking them to sit through a couple of hours of usability testing meant they would not be contributing to team velocity.</p>
<h4>His complaint: “It feels like the designers are part of a different team sometimes. And then they’ll play the ‘I’m the expert’ card instead of having a discussion.”</h4>
<p>Jack explained that many of the artifacts included in the user stories he received — high fidelity mock-ups and detailed design and interaction specifications — to him, meant design was done and he needed to start building. With such polished design artifacts, the likelihood of being able to discuss design alternatives was low, even if he had concerns he had about the level of effort or impact on the system as a whole. I knew that my intention with similar artifacts had been to preemptively answer implementation questions, and I would have to change my approach if I wanted to encourage developers to initiate design discussions, particularly since this sounded like a place in the UX design process where they potentially wanted to be involved.</p>
<h3>My Solutions</h3>
<h4>Deliverable Change: Construct User Stories that Feel Like Conversation Starters</h4>
<p>The first thing I did was start to put the acceptance criteria (not acceptance tests) front-and-center on my user stories, a list of what should be addressed to satisfy user pain points or allow them to complete tasks. I made it clear that the design could change as long as the acceptance criteria could still be met. To emphasize the point that the design was up for discussion and change, I also started including wireframes instead of higher-fidelity mock-ups, unless the point of the story was specifically to handle visual design.</p>
<h4>Process Change: Estimate User-Value and Technical Feasibility before Prioritization</h4>
<p>I wanted to give developers an easy way to see, on a story level, how much value they actually represented to the users and the organization. I’ve done this several ways on different projects, but one method I like to use is the <a href="http://www.slideshare.net/adlininc/ad-hoc-personas-virtual-seminar-preview">persona-weighted feature matrix</a> developed by Tamara Adlin which has stakeholders estimate how much value each features brings to each persona or defined user group. Then when I get the developer point estimates for the same feature set, it’s easy to create a graph with quadrants showing what’s technically feasible vs. what will bring value to the users:</p>
<p><img alt="" src="https://cdn-images-1.medium.com/max/545/1*4PECMUL9T6_niERbL69C5Q.png"></p>
<p>With both user-value and technical feasibility quantified, it was not only easier to plan, but we also knew which features needed to be redesigned (with input from the development team) or simply not built.</p>
<h4>Deliverable Change: Summarize Usability Test Findings into Small, “Demo-able” Artifacts</h4>
<p>Most teams I’ve worked with followed an Agile framework called Scrum, which meant that every two weeks the entire team gathers and shows what they’ve produced over the last couple of weeks. I started presenting my usability test findings in these demos, cutting my normal deliverable down to a 10 minute presentation and bringing in video clips wherever possible to highlight my main points. I would summarize the recommendations into a few bullet points and try to communicate the scale of the recommendations (e.g. label changes vs. new feature ideas). I also made it clear that I wouldn’t put feature designs into the backlog without discussing the technical implementation with the development team first.</p>
<h4>Process Change: Only Ask Developers to Observe Testing in Very Special Cases</h4>
<p>In most cases, the short demo was enough to get the developers the information they needed from the usability testing. However, in cases where I thought a feature needed special attention, I would get approval to run usability tests and fixes within a timebox (an agreement to work on something for a period of time with a clear cutoff date and time) with 1 or 2 developers. This way the developers, and the rest of the team, could plan and measure the activity like anything else they’re working on, instead of worrying about the unknown scope that can come from usability test findings.</p>
<p>When I run usability testing in a timebox, I conduct 2–5 short usability tests up front asking the developers to attend the first couple of test. At the end of each test, we have a quick meetup to make sure neither of us, the UX designer or developer, has spotted something significant to be worked on immediately. At the end of all testing, I’ll catch the developers up on anything else I might have observed and we’ll work together to figure out what should be addressed now and what is worthwhile to surface to the group as backlog items.</p>
<h3>Summary</h3>
<p>If you’re a UX Designer looking to improve your relationship with the Agile developers on your team and get them more involved in the UX design process, you need to approach the situation the same way you would any usability problem — by continuously asking “why?” until you identify the root cause. And while my original insights might have been gained from the conversations I had at home, I now know I can have these same conversations with the developers on my project teams and doing so results in a better process and product.</p>
<p><em>Originally published May 26, 2016 on the Aquilent Blog</em></p>
<p><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=4173a60a8172" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="https://blog.prototypr.io/agile-ux-what-i-learned-from-living-with-an-agile-developer-4173a60a8172">Agile + UX: What I Learned from Living with an Agile Developer</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


Agile + UX: What I Learned from Living with an Agile Developer

Top Stories