Pairing the Agile UXD to the traditional BA-Dev-QA Agile Triforce.
TL;DR Being a UX Designer is complicated.
Being a UX Designer on an agile software development team is akin to a drunken mechanical bullride at that western theme bar. Ok maybe not. But I think I'm qualified to ride one.
For one thing, we have so many different skillsets that it's always really hard to know exactly how to staff us on projects without first knowing what each designer does.
That being said, from my experience on agile software development projects (at least at ThoughtWorks) I've seen the following patterns:
UXD teams are staffed to counterbalance our skillsets - as being more on the business side with BAs, or more on the dev side as Visual Designers/UI Devs or as researchers. HOORAY PAIRING! or TRYING! (what happens when three people pair)
As projects progress and we go into delivery mode, we tend to get more and more specialized in our roles and division of responsibilities. Good things and bad things can come out of this.
Good thing: Divide and conquer allows us to get work done faster. I can focus on IA and ID in story writing while you focus on UI dev / implementation of visual design.
Bad thing: You become too siphoned from your team mates and could end up having no idea what the other person is doing.
Most of my experience at ThoughtWorks has been with small agile teams where I play UX/BA and I am paired another UX/UI Dev or a researcher.
What the hell is a UX/BA?
I joined ThoughtWorks 2 years ago initially as a Business Analyst (because we didn't have a UXD practice yet) and I received the BA training at our awesome JC program in India. As BAs we learned how to:
understand business goals
capture features/requirements
discover user scenarios / acceptance criteria
prioritize/negotiate stories with clients and our dev team
Afterwards I was staffed as UXD on projects and leveled up my skills in:
In understanding both sides of the roles, I have been staffed as the UX/BA. This did not necessarily mean doing the work of two people, but moreso helping make the collaboration easier on teams. However I have found the UX + BA process more streamlined when you are able to be both UX and BA. For example, I can understand how to prioritize and vertically slice features into stories, which helps me strategically think about how to design for these clusters of stories in each iteration rather than get overwhelmed and try to design the entire app in one go. There is a time and place for high level design visioning, and it is not at the story level.
UX and BAs have much in common, especially in the realm of product design, business analysis, IA, and ID. But oftentimes we butt heads if we don't understand how the other works.
I asked some of my colleagues for their experiences in pairing with UXDs/BAs. Here's some examples of how these pieces could fail to fit together:
When the UXD is trying to ideate and design features in wireframes, the BA says "that's extra scope", "these wires don't match up with what our stories define as requirements", or "you've forgotten to design for xyz scenarios".
When the BA gives UXD a story to design for, the UXD says "there's way too many acceptance criteria in here", "how does this fit into my design?", or "there's weird scenarios in there that we don't need to design for".
UXD not being able to deal with a BA's backlog
BA not being able to deal with the uncertainty and oftentimes lack of deep analysis on a UXD's sketch to code process
UXD and BA not agreeing on how to assign value to a story for it to get prioritized
The list can go on. I'd like to hear your experiences here.
I believe that these failures are not a failure on our agile process, but rather a failure in communication and knowledge gaps. The more BAs and UXDs reach out to each other and learn about each other's processes/skills, the more empathetic we can be and help each other find a middle ground when it comes to differences in our workflows.
One easy trick to start with - talk to your BA / UXD prior to the start of a project about your curiosity in what they do and discuss their processes.
What if we don't have a BA for the UXD to pair with? A.K.A. Who are those "pesky" QAs?
When there are no BAs, I have had success pairing with QAs to write stories with. (Again these are small agile projects where I doubled up as BA). QAs are amazing creatures. They are the beautiful magical unicorns of the Forbidden Forest! Ok maybe not, but have you ever met a fire juggling unicycling QA who will write stories with you like no tomorrow and write you a fully automated test suite at the same time? I have. I was fortunate to pair with Robin on my last project, who wrote a great blog post about his experience in doing BA work as a QA.
ok so this picture isn't actually of Robin. I have no pictures of Robin. So I stole one off t3h googles. But this is what Robin basically looks like. Every day. Minus the weird 90s tie dye outfits.
We constantly paired on analysis for our stories. Robin helped me think of all the possible scenarios (things only a QA would think of! Those crazy magical unicorns.) and gave great input on interaction design for each scenario, especially for error handling and validation.
We had a sweet checklist for each story before moving them to "Ready for Dev"
One caveat. If you are a UXD and you find yourself in a situation like this where you get to pair with a QA (or a BA), don't be shy in pushing back and saying no to designing for every scenario that a QA or BA will think of. Some scenarios may not be high priority and it's ok to design for them later in a separate story.
OK great! Now how do I pair with Devs?
A good starting point in pairing with devs is learn to write some code. If you are the UXD who is responsible for making sure design gets implemented, you need to learn some HTML/CSS and even HAML/SASS (then you can impress those devs with the shiny new toys). Otherwise you will have to take some time out of your day to sit with the devs after they have developed most of the functionality of a story. Work with them on the UI polish by telling them what you want, and watch them code and update the view on their localhost.
Even when I play UX/BA on a project, it has been helpful to know code for deskchecks with a dev pair. If I see that the design is a bit off, I can sit down with them and spend 10 minutes to tweak the CSS. It's even more helpful when I understand the client's existing SASS architecture and just tell the devs which classes to use in their HTML so they can easily pick up existing styles for elements on their page. How much time you can save there if you just learn some code?
Thiiiiiiiiiiiiiiiis much!
But I already have someone on our team who can handle the UI Dev work! A.K.A. why don't our developers know CSS?
If you have someone who's great at implementing visual design on your team, great! Maybe they are a dev who knows front end, or maybe they are another UXD who can code. The challenge in pairing now becomes really to keep them in the loop on the prioritization of stories in your pipeline. Getting their input in interaction and visual design is easy. Making sure they don't get swallowed by the dev team and become just a dev monkey is harder.
Set expectations for your dev team that they are responsible for writing good markup and CSS, or at least learn. You'd be surprised at some of the knowledge gaps your brilliant developers might have when it comes to front end work. Your UXD pair who can code should not be the bottleneck to your entire dev team on UI cleanup. Also this takes your pair away from you when it comes time to work on interaction/visual design. And we all know what happens when you don't pair.
discoholicmusic
amandla
turnnoffyourmind
snowghoul
tangentwithtanner
germansingergirl