The ONE SKILL every UX/Product Designer should master to strengthen their agile product team

And it's not how to write a catchy, click-baiting blog post title.

I’ve worked on several agile teams as a User Experience (UX) and Product Designer going back to when agile, scrum, and similar terms were new to the industry. Before those ideas were applied to software development, most teams worked in a waterfall-style similar to how designers in an agency often work. The designs were created, tweaked, reviewed, critiqued, re-tweaked, and eventually sent to a team of developers in the next wing over to be built and released to customers.

The A-Team

I won’t go into the details of what the agile methodology entails but suffice to say agile changed the waterfall process by putting designers and developers on a team with a product manager (and possibly a Scrum Master, UX Researchers, and Analysts) to hash out the design, development, and implementation together using an incremental approach. I’ll refer to these as product teams but have heard them called scrum teams or agile teams as well. The point is, that you’re all in it together and hopefully given the autonomy to meet business goals as your team sees fit instead of being handed a list of specific tasks to execute in hopes of reaching an outcome.

If you’re a UX/Product Designer, you’ve probably learned a little about a lot of skills during your time in the discipline. Beyond the design part itself, there are things like user research, product strategy, accessibility, motion design, prototyping, etc. to consider. So how can I narrow these down to ONE SKILL? Would you consider it cheating if I told you the skill I’m referring to is actually adaptability?

Born To Run

Work on an agile product team goes in cyclical phases called Sprints. There are a number of ideas regarding how many phases and what each one is called but generally speaking they all consist of planning, designing, developing, deploying, and reviewing. NOTE: Some add testing as a specific phase but for design testing, I prefer testing early and often so literally at every point starting before any work is done through to the completion of the work.

Sprints can be one to four weeks in length with the team’s goal being to end the sprint by delivering a working product (or often product enhancement). At the end of the cycle the team takes stock of the working software they’ve built and circles back around to make another pass in hopes of continually improving both the product and their customers’ satisfaction with it. Adaptability allows you to cycle through the different skills you’ve acquired as a designer and apply those as needed during each phase. So let’s look at the basic phases again and what skills are best applied for each.

Planning 

Sprint planning, sometimes referred to as Discovery, puts everyone on the team together to discover the highest value work that can be done in the given time. Planning takes into account business needs, user research and customer feedback, technical constraints, and design needs. It can be a delicate balancing act, especially when stakeholders are all clamoring for their highest priority items to make the top of the list. For this phase, I think the most important skill a designer can have is diplomacy.

There is a lot of finesse that occurs with the specific type of bargaining used in sprint planning second only to negotiating market stall deals in Egypt. You want everyone to know that yes, their needs are extremely important but coordinating everything in such a tight timeline requires give and take. Diplomacy requires active listening, making sure you understand what is needed and why. It can also require tactful pushback on some occasions. Sometimes it comes down to revenue, other times different goals may take precedence. Just remember to keep the bigger picture in mind. There’s always the next sprint.

Designing

Once you know the work to be done, you can start looking at how your design can support your team’s goal. In most cases, this won’t mean reinventing the button or “in the weeds” type work where you’re breaking everything down the base pixels. A well-executed design system, which most mature design organizations now use, can take care of details that used to involve pairing up with developers for a tedious pixel-pushing session. With these elements already solved the designing is just drag and drop, right? At the most basic level, sure, but your goal isn’t designing something “basic” is it? The modern design phase requires skillful inventiveness.

Using processes like design thinking and other exercises can help get the ideas flowing, there is no need to stop at basic. This is your pass to get inventive. Zoom in, zoom back out, think about how what you are designing now could be used elsewhere. Make sure that if the work is based on a business requirement, you can squeeze in something that boosts, even slightly, your customer satisfaction (CSAT) rating. If the work is more customer-focused, how can you add or, at a minimum open the door for, something that increases revenue? Product team design work is never a one-and-done process and remember, you’re designing for a digital ecosystem even if it’s a single product.

Developing

After you’ve created a design that aligns with the team’s sprint goal (and tested it, preferably with actual users) it’s time to build it. You may think that as a designer, your work is done. After all, developing is best handled by developers, right? Not if you have mastered the skill of collaboration.

Working on an agile product team is literally all about collaboration but during the development phase, I find it especially important. If you know enough front-end design to be comfortable writing code, offer to help out and take on some of the styling and/or layout work so developers can focus on any necessary back-end work. Offer to test the previous day's work on a staging server to make sure everything is working as designed. Are there questions about which route to take with interactive elements? Try running some user studies on each to see which resonates best with your customer. If there’s nothing else to do and your product roadmap is well defined you can often work ahead so that you have a head start on the next sprint. The point is to step outside of your comfort zone and add value by working beyond your role. The more you learn, the more valuable an asset you are and the stronger your product team becomes.

Deploying

The deployment phase is when your finished software is released to a production environment allowing live customer access and real-world integration with the other parts of your digital ecosystem. During this phase, I’ve found it most helpful to put on my analytics hat and help with any required QA or release testing. Some teams have designated QA testers but if not, everyone can chip in to make sure there are no surprises as your newly developed code is released to the wider world.

You want to make sure you’re testing every possible scenario a customer may encounter. While doing this, look at the design elements like motion, interaction, and of course layout to make sure your finished product looks and functions as you designed it. Is the necessary data being presented correctly? Are the right sections and pages loading when triggered by users’ selections? Are design system components displaying as intended? What about using a screen reader to navigate? Every aspect should be analyzed as thoroughly as possible to ensure optimal performance for your customers.

Reviewing

In my experience, the sprint review sometimes called a retrospective, is as much about the team’s performance as it is about the software the team built and released. How did the team handle setbacks and challenges that came up during the sprint? What does that mean for the work you’ll be planning in the next sprint? Was the team able to pivot when an issue popped up or did progress grind to a halt? Critical thinking skills really shine here, as well as demonstrating trust and accountability.

Be transparent about what you could have done better or how any missteps were or can be corrected in future sprints. Own your mistakes and learn from them. After all, continuous improvement isn’t only for your product but for your team as well. You and your team learn about each other’s strengths and weaknesses and how to best work together with each successful sprint you complete. Trust that everyone is doing the best they can with the information and resources they have available. Remember this and be thoughtful when offering suggestions on what things you and your team can improve on going forward.

Do It Again

The review runs directly into the next planning session in most cases. Goals are adjusted and everyone sets their sights on the next milestone to be achieved. From these examples, you can see that being a designer on an agile product team is less about the singular skill of design and more about flexing and refining other skills you’ve undoubtedly learned along the way. If your team and your design organization are high performing, this will eventually mean doing less textbook-style “design” in most cases and more of what actually makes the work happen, which is everything else. Adaptability means being able to seamlessly summon the power within many different skills and apply them when most beneficial to the process and the product team’s work.