From real-time pair designing and developing, to weekly sprint cycles and even to monthly sprint cycles, what we’ve come to understand is that Agile has many meanings depending on who you ask.

At the core of the entire Agile enterprise is the user experience Designer (UXD). A UXD must wear many hats: they must work very closely with product managers to understand requirements and business intent; with developers and testers to ensure everything is implemented according to the UX specifications; with stakeholders to defend the user experience and to move the needle in the right direction (what the user needs v.s. what the stakeholder wants). It’s never easy to be in the UXD’s shoes (http://www.ymedialabs.com/ux-architect/). 

Various UXD’s take different approaches to dealing with many of the challenges that come up in a work environment. Some are contextually specific to the company where they work, others follow the agile practices to the letter and yet others are a combination of “rules” and “realities” in the field.

What we wanted to think through is whether there is a pattern that UXDs could follow methodically and get the best results regardless of where they work. That goes beyond simple collaboration between various parties as a principle. It goes to how a UXD should interact with various members of their teams, the mindset they should embrace, and the concessions they should be willing to make. That’s what this article is all about.

Specifically, we will try to answer the following questions which are both strategic and tactical at the same time. Stay with us if you want to know the answers.

1. The relationship between the user experience designer (UXD) and product owner (PO). Who expects what? What does a perfect UXD and product owner relationship look like?
2. The relationship between the UXD and the visual designer. What are the positive outcomes of working together? How can you avoid communication pitfalls? 
3. The Interaction between the UXD and the front-end developer. Who expects what? How can these two seemingly different disciplines collaborate more efficiently?
4. The interaction between the UXD and other stakeholders, outside of the Agile pod: how the UXD and the PO form a unified view and defend that view to make small, incremental improvements while getting consensus across stakeholders.
5. How UXDs interact with other UXDs? Few companies have only one UXD or only one pod. Usually, multiple teams work on a variety of verticals. How is consistency achieved across UX teams when Agile is structurally designed to maximize output at the pod level and not across Agile pods?

The relationship between the user experience designer and product owner

To understand the ideal relationship between a user experience designer (UXD) and a product owner (PO), we must first understand the responsibilities of each role during the project.

The user experience designer on an Agile team is expected to design the end-to-end experience for a product. A UXD creates the plan that will change and improve the experience for the end user. This is their main focus. To accomplish this, they must understand the business goals and user needs, and collaborate with each member of the team and the clients to create the best user experience. UXDs are responsible for research, wireframe creation, task analysis, creating prototypes, and UX testing.

How UX fits into an agile team. Image courtesy of joseph-cohen.co.uk by QBurst.

The product owner has changing roles and responsibilities during the project. The PO is responsible for gathering the initial requirements provided by the client and creating, with the team, a set of user stories which are placed in the backlog. During the sprint, the PO must be available for the team at all times. The PO also has to groom the backlog. If these tasks seem like something a UXD could also tackle, consider some of the additional tasks a PO is responsible for:

1. The PO discusses demo results with clients more than once. Clients can be hard to wrangle, so hunting down clients can occupy much of the PO’s time.
2. The PO has to learn the product from a user perspective in case they must demonstrate the product with help from the team.
3. POs are always on the lookout for requirement issues that crop up along the way, which they will have to define. The PO also studies the product market and monitors what their competitors are doing and this may generate more requirements.
4. The PO is responsible for the burndown chart and will have to predict whether or not the work can be completed in time based on the burndown rate. If the team won’t be able to complete tasks on time, the PO must figure out what can still be finished on time.

In short, there are more than enough tasks to keep each team member busy in their role.

The role of the product owner in an agile team. Graphic courtesy of Roman Pichler

Knowing the differences between the two roles now allows us to define what we think is the ideal interaction between product owners and UXDs.

The perfect relationship between the UXD and the PO is a very close one. POs and UXDs need to work together to create the user stories, and in most cases, additional stories that will enhance current functionality. The UXD can also help the PO clarify the business value from the UX decisions.

Having regular design review meetings between the UXD and the PO is a must. Decisions keep changing and regular check-ins with POs help keep the UXD’s priorities in order. POs expect that designers will be transparent about their progress, and share their updates and user testing findings. In return, UXDs want the value of their expertise to be accepted by POs and to be trusted.

The relationship between UXD and Visual Design

Visual designers practice the art of deciding how things should be communicated to users through text, images, spacial relationships, and the placement of various Visual elements. Visual designers concentrate on the look and feel of the product and brand, as well as being involved in conversations about what the product provides, and project goals. Visual designer activities can include choosing the color palettes, photos, graphics, and fonts. They are also often responsible for creating static, highly detailed, pixel perfect, non-interactive redline layouts that are passed to front-end developers. 

The roles of the user experience designer and the visual designer. Graphic by Bethany Lankin

Visual designers know that their job is to influence a visitor’s psychological state of mind and perception of your business. Through their craft, visual designers inspire emotions and responses. These are the people that are responsible for causing users to “fall in love” with your site. A visual designer ensures that a digital product will capture interest, hold it, and bring in sales.

While user experience design is also concerned with the appearance of the site, the UXD is more interested in things like how the users interact with the site, navigate through the site, and make decisions about where to click or not click. User experience designers explore the information architecture, which is the organization and display of the information on a site. The UXD ensures that a digital product is an intuitive, engaging, pleasant, and invaluable experience. While a few UXDs have some experience in the visual design field, don't expect them to be artistically inclined.

The two documents on the right are produced by the UXD. The last image is created by the Visual Designer. Note that not only has color been added, but that some elements in the wireframes are arranged differently in the final visual design. Visual provided by Jess Eddy.

These roles are two sides of the same coin, and both are fall into the “creative” category. UXD and visual design should also have a very close and collaborative relationship. They should be able to marry their work together and be able to find some common ground. After all, their roles have a lot in common:

• Both are concerned with the psychological state of the user.
• Both have to deal with other team members seeing them as “pixel pushers,” whose job is to “make the digital product pretty.” Sadly, it is not uncommon for other team members to think that anyone who can learn how to use a prototyping tool like Principle, Invision or Flinto and a mock up tool like Sketch, Illustrator or Photoshop will instantly become a UXD or visual designer.
• Both have a tendency to struggle with Agile in the beginning because the fundamental premise of the Agile methodology – “do just enough to make it function” – doesn’t match with the traditional design view – “Keep at it until it’s perfect.”
• Both have to deal with the fact that all design is subjective. If someone codes a dropdown box, you can immediately see if it’s working or not. It’s more difficult to determine exactly when a design “works.”

Too often, teams have depicted the relationship between these two roles as linear, with the UXD completing a wireframe and “throwing it over the wall” to the visual designer with little explanation. Only after it’s been built does the UXD discover that they their design has not been specced out the way they wanted it to be. The look-and-feel can have a great impact on usability, and often times something is released that looks great but doesn’t serve the user.

To avoid these pitfalls, collaboration is the key. Remember that user experience designers and visual designers both want respect from the other. You won’t create a superior product if your UXDs have an “I’m going to throw this over the wall, now you figure it out” mentality. And a user experience designer can’t thrive if they feel their user-friendly interactions are being sacrificed on the altar of beauty.

Ultimately, you have to remember that you are working with a person, not a role, and you can use each other’s strengths. It’s helpful to discuss and then work in parallel, chatting back and forth during the process and fostering a document exchange culture.

UXDs and visual designers can’t be afraid to take or give criticism. It’s important to keep in mind that each person wants what’s best for the user, and sacrifices often have to be made to meet that goal.  The visual designer may design a gorgeous site that doesn’t get results and the user experience designer may design a fabulous widget that tests poorly with users. If you have to choose between the beautiful design and the less beautiful design that works, you must choose the design that works for the users.

You may also be interested in this comparison between UX and UI designers.

The relationship between the UXD and front-end developers

Image source: https://www.upwork.com/hiring/development/front-end-developer/

A front-end developer, also known as a front-end coder, is a computer programmer that codes and creates the visual front-end elements of a software, application or website. He or she creates computing components/features that are directly viewable and accessible by the end user or client. Typically, the front-end developer's job is to convert digital product’s design files into raw HTML, JavaScript (JS) and/or CSS code. This includes the basic design/layout, images, content, buttons, navigation, and internal links. The end result is code that serves as the digital product’s front-end structure, which is used by a back-end developer to add business logics and connect databases and processes, among other processes. 

Image courtesy of Browserling

At first glance, the user experience designer and the front-end developer seem more removed from each other than a user experience designer and a visual designer, or a user experience designer and a product owner. This is due, in part, to the traditional user experience/engineering engagement model, where the UXD and visual designer roles are seen as separate from front-end and back-end engineers. Even worse, the old model suggests a linear path from the UXD to the visual designer and then to engineering, with little interaction between the roles.

The old way - A traditional User Experience/Engineering engagement model

 In this system, the designers are concerned with delivering great experiences and solving user challenges through design, while the developers are concerned with solving technical problems with code. In this relationship, where front-end and back-end developers are grouped together, the front-end developers tend to focus on solving back-end technology issues and creating code for code’s sake, regardless of whether it delivers any value to users. When FEDs only collaborate with engineers, they’ll inevitably try to make their code meet engineering’s goals.

Common problems with this model occur when the UXD and visual designer throw wireframes and mockups “over the fence” to a FED who returns with the pronouncement “You can’t do that.” Or your carefully crafted, pixel-perfect spec was not followed to the desired level of fidelity, or differed in a major way from your design. When the UXD and the FEDs don’t collaborate, these common issues generate more meetings, extend deadlines, and create a general sense of frustration between everyone involved.

Because of these issues, many people think that front-end development should be more strongly aligned with design than with development. When the front-end developers are allowed to collaborate with the UXD, they’ll be more sensitive to meeting the design objectives, including developing perfect representations of the UX designs.

UXDs can benefit greatly from front-end developers who, because of close collaboration, are now more likely to propose new and more viable ways of solving a problem rather than simply saying, “That can’t be done.”

FEDs also encourage new ways of thinking about design, and their contributions can often help improve a basic interaction model and wireframes. FEDs can also mediate between UX designers and back-end developers.

The new way - Engagement model with Front-End Engineering integrated into User Experience

Successful FED and UXD collaborations don’t only involve FEDs who understand user experience design basics. The UXDs should also learn the basics of coding. UXDs that have some code literacy skills are more likely to understand what is possible to build and what impact the UX decisions have on development. They can relate to developers better, and understand how and why problems occur. Understanding code creates more opportunities to create original content.

These ideas of mutual learning between FEDs and UXDs are not, by any means, revolutionary. Already, the Learn-to-Code movement has been growing in popularity. There are even places like Codecademy that can help people learn to code for free. 

In short, the UXDs and FEDs should work together and collaborate on each other’s work. Both sides will feel more empowered and each will learn something about the other’s skill sets. 

The relationship between the user experience designer and the stakeholders

A user experience designer’s work will find acceptance more easily if they’re able to speak the stakeholders’ language, visibly embrace everyone’s values and explain why their own UX aims are aligned with the business needs. Being a great user experience designer is about being a great communicator. And while many times the product owner will be the one to deal with a “difficult” stakeholder on a UXDs behalf, UX designers must to be able to articulate why their solution solves the problem. 

Many novice designers ask themselves, “If I’m the expert, why should I have to keep defending my choices?”  When creative people have to explain the choices they’ve made to non-creative people, communication channels often shut down. But there are some things that a UX designer can do to help facilitate the conversation. Empathy is the key to working with stakeholders. Try to put yourself in their shoes.

It’s essential for the success of the project that the UX designer gains the trust and support of all of the stakeholders. When they don’t have their support, the designer ends up having the same conversations over and over. Requirements end up being re-written because the UXD couldn’t effectively explain why they made the decisions they made, which can lead to a compromised user experience, like the CEO Button.

From Tom Greever’s presentation "Articulating Design Decisions"

The three things the UXD and PO need to keep asking stakeholders are:

• What will success look like to you?
• What is the problem you're trying to solve?
• Who is the audience you're trying to reach?

As long as everyone is focused on the answers to those questions, fruitful collaboration between stakeholders and UX designers can begin.

Especially in an Agile environment, UXDs must demonstrate a wide variety of soft and hard skills. Here’s a list of the minimum required skills:

Listening

Listening to stakeholders sounds obvious, but it’s easy to be in the room but still not be present. The UX designer should let an individual stakeholder talk as long as they want without interrupting them, even if they think their idea doesn’t make sense. Most people love to hear themselves talk. Sometimes, if the stakeholder has proposed something preposterous, another stakeholder will jump in and argue against their idea, saving the UX designer the burden of having to do it themselves. The most important thing is to make sure every stakeholder feels as though they’ve been heard.

Offer Solutions

The UXD can engage stakeholders by asking them what problem they are trying to solve with their proposed solution and offering some alternatives to what they’ve proposed. In some cases, they may even want to suggest some less attractive alternatives because once a stakeholder realizes there’s more than one way to solve the problem, it will keep the dialog open.

Keep things positive and upbeat

No mater what a UX designer might think of a stakeholder’s idea, they should always respond first with a “yes.” This implies that yes, I understand your suggestion. Yes, I have taken it seriously, Yes, I understand where you’re coming from. Yes, we are on the same team, trying our best to solve the problem at hand.

Don’t use jargon

The UX designer should not rely on jargon to make their point. Using fancy UX words just makes it seem that the UX is trying to “one up” the stakeholder. Make sure the UX designer can explain why they designed what they did in layman’s terms. Starting a sentence with the phrase, “from a design perspective…” just sounds like “from my perspective,” which sounds like, “from my personal likes and dislikes.”

Image taken from Martina Hodges Schell’s presentation “Talking to stakeholders: 13 communication anti-patterns that block good ideas”

The UX and PO can rationalize the design to stakeholders by saying that it does at least one of the following:

• Facilitates a primary use case
• Is an established pattern
• Meets a particular goal
• Has data that supports it
• Complies with a standard
• Is limited by technology
• Draws the users’ attention
• Conforms to the flow

The UXD expects to get a great deal of help from the PO when defending design choices. In the best case scenario, the UXD rationalizes their design decisions to their PO who likely has a more familiar relationship to the stakeholders, and may have had time to understand their individual motivations and desires. That way, the UXD and the PO have a unified vision to defend choices to make small, incremental improvements while getting consensus from the stakeholders.

How to achieve UX design consistency across multiple pods and verticals

It’s true that most companies have multiple teams working on different aspects of the same product, or even different teams working on different products at the same time. When each UX designer is trying to solve their pod's problems, it’s difficult to know if each designer is reinventing the wheel each time they need to solve a design problem. There are many good reasons to strive for UXD consistency, for example, streamlining the design, development, and maintenance process.

 First, let’s talk about the different kinds of consistency people have in mind when they discuss product consistency:

• Style (ex. fonts, colors, layouts)
• Branding
• Behavioral consistency
• Information architecture and layout

Typically, the visual designers are in charge of making sure that the styles and branding of the products are consistent (through the use of corporate branding and style guides). But behavioral consistency and the information architecture/layout is the domain of the UXDs. Consistency can be managed across teams in the following ways:

• A UI pattern library
• Wireframe guidelines
• Attending regular UXD meetings and sprint review meetings
• Appointing a UX Director or UX representative at the leadership level

One way to achieve cross-pod consistency for user experience designers is to create a user interface pattern library. User interface design patterns are recurring solutions that solve common design problems. Design patterns are standard reference points for the user experience designer. Your UXDs can identify common patterns that will re-occur in different areas of the site, or on companion sites. After the pattern has been added to the library, each UXD only needs to copy and paste the pattern onto their wireframes, ensuring consistency across pods. 

An excerpt from Sears’ pattern library outlining when to use and not use Layers in a design

Another artifact the UXD team can create to create cross-team consistency is a set of wireframe guidelines. This is a document that contains rules about how a wireframe should look, including indicator and annotation colors, placement, publishing rules, document storage, how to display variables, what FPO indicators will look like, etc. If a UXD, visual designer, or front-end developer is required to move teams, there is no confusion about how to read another user experience designer's wireframes, and teams can get up to speed much faster.

Finally, you should consider appointing a UXD director or lead. It should be someone who can direct the UXD team, oversee its output, and ensure consistency. It should be someone who can contribute subject matter expertise in the areas of information architecture, interaction design, user experience best practices, user research, and online user behavior.

The director should be the pattern library champion. They will also be responsible for fostering a creative, efficient, and collaborative working environment for the team. All the UX designers need to feel as though they are part of a collaborative team as well.

Summary

Every company, in one way or another, obsesses over collaboration. It’s a buzzword that’s thrown in at every opportunity. 

If both the Agile team members and the stakeholders commit to solving problems with the users' goals in mind, if individual Agile team members and stakeholders respect each other’s roles and try to understand each other’s points of view, and if team members and stakeholders embrace change and collaboration, the most successful and consistent version of the product can be delivered in record time.

Codrin Arsene is a technology writer and a senior product manager. His areas of expertise include digital marketing strategies, UX/ Design and bottom of funnel conversion and optimizations. He is a Content Writer with Y Media Labs where he writes on mobile app strategy, analytics, marketing strategies and online business development.