In the Karate Kid (the first one, aka the good one) the seemingly innocuous Mr. Miyagi takes on wayward Daniel-san and teaches him to totally kick-ass in karate. While the movie is a prized trinket of 80’s pop culture, heartwarming and by all measures a classic at this point in time (it came out in 1984!!) there are some terrific lessons to be learned from the way Mr. Miyagi taught Daniel-san how to fight. These lessons translate directly to learning any skill but, for the purposes of this post, I want to apply them to Agile and user experience design.
I was speaking to an entrepreneur the other day when he mentioned he was looking for a “creative director with UX skills.” He added,”…someone whose aesthetic I really like.” I responded ,”Good luck.”
For the past 4 months I’ve been functioning as the Product Owner for my Scrum team. Interestingly, I’m also the UX designer for the team. Many articles point to the challenges, at times seemingly insurmountable, that this dual-role creates. While those challenges are indeed rearing their, err, challenging heads, let me recap how the team has worked through them.
Challenge #1: There is not enough time to be the PO and the UX person
Both roles are full-time jobs. How does one reconcile and/or prioritize the obligations pulling in different directions?
The answer is to get those obligations pulling in the same direction. The PO has the business’ needs in mind. The UX designer has the user in mind. But, the UX designer’s job is to bridge the gap of business and customer. By having both those needs clearly defined and in the same person’s brain, a synergy is created which allows the singular UXPO (yes, I like that) to conceive early design ideas that already conform to the business’ requirements.
Challenge #2: developers need constant direction about what’s coming in each iteration.
The UX designer, working in parallel with the rest of the team, is constantly providing assets, answers, and feedback. The PO is looking ahead to the next iteration, as well as the next theme. The challenge has been focusing on the present and the future at the same time.
The way I’ve handled this is by splitting my time in the iteration. Early in the cycle I work on the immediate needs of the team. The thing you’ll find is that even if you’re employing Lean UX tactics, you still design well ahead of the dev team’s capacity very quickly. This turns out to be a good thing when you’re the UXPO as it opens up days in iteration for you to look towards the next set of cycles. What I’ve also found effective is, as you’re deciding where to focus in the near-term, bringing in the team for quick brainstorms, affinity mapping exercises and design studios offers perspective, insight and a welcome (short) break for them from the monotony of long coding days.
But wait! There’s more! The added bonus is that by involving the scrum team in these activities, they’re a part of the planning, know exactly what’s coming up and are already bought in to the plan (because they helped create it).
Challenge #3: Approval cycles can be notoriously long. How can the UXPO keep the trains moving while securing executive buy-in for the team’s efforts?
To solve this challenge I’ve had to become a UXPOlitician (hot!). I have a vision of where I’d like the product to go. While we execute tactically on the immediate needs I’m constantly chatting, formally and informally, with my internal stakeholders. We bounce our new ideas off of them and get a read of the general vibe. This shapes the vision and we discuss it further. By having these conversations well upstream in the process, our review cycles focus on the very tactical elements of the work – not the strategic choices we’ve made. Those decisions were settled a while back outside of the iteration machinery allowing us to keep the cyclical nature of Agile development moving forward at constant and, hopefully, increasing velocities.
These are just three challenges I’ve faced as the UXPO. What have you faced? How have you solved it?
Over and over again, it seems, practitioners within the User Experience world stir up flame wars and heated debates about what it is exactly that we do and what it should be called. From Interaction Design to User Experience Design to Information Architecture to UI Design, titles and job specifications vary as frequently as Sean Combs’ stage names.
Here’s a suggestion: stop trying to define the damn thing and, instead, design the damn thing.
Design it. Get your hands dirty. Make sketches, push pixels, build prototypes and create experiences. Just do it. Forget your title. Forget your job description. Focus on the business problem you’re solving. Then figure out what you’re best capable of doing that will lead to a successful solution for that problem. Work within your organizational constraints or break new ground. Regardless, solve the problem. Understand your user. Understand the business goals. Do the right research and apply that learning to the solution.
Instead of using titles and job specs to describe the value you bring, show it. If you spend your time designing the experience and solving problems instead of defining where your cog fits in the machine, your true value will become obvious. The more your value becomes obvious, the less the need for specific job titles and descriptions.
Pretty please, let’s stop defining the name, boundaries and specifications of our profession. Instead, let’s solve problems, innovate and simply design good experiences.