The Business, Developer,
and UX Design Relationship

A Brief History

Ask any user experience designer who's been in the industry for ten years; 'did you have to teach business leaders what your job was?' and they can regale you with stories of explaining what user experience design is, to having to show the outcomes of their work, or even justifying why UX is important.

Today, UX work is more commonly accepted as an essential part of digital product creation. The days of having to explain why Word and Excel do different things but can look the same are over. However, as I have been applying to new positions and getting a new perspective of where my industry is, I have seen a common question come up. "How do you think UX should work with developers and the business"? I've seen all sorts of variations on this question too. "How closely do you work with developers?", "When have you deviated from your system and why?" and, "who has the final say over a product?".

Having spent over fifteen years in the user experience field, I've developed answers to these questions that guide me to when I need back off as the designer and, more importantly, when to push ahead. It starts with understanding the relationship between the business, the developers and your role as a designer.

The Business

If you were to ask me 'what is the most essential part of being a user experience designer?' I would say, "being an advocate for the end user". Without doing that, it is pretty impossible to do good user experience work. However, the more senior I become and the more experience I've gained, I found the value in understanding the business side of things.

You can have the best user experience in the world but if the product doesn't make money, or accomplish a business goal, it's worth nothing.

There are exceptions, government work, health care portals, and non-profits (to name a few). But even then, these products, while not necessarily generating money, are there to accomplish a business goal.

This is the first place I will bend as a user experience designer. I will always be an advocate for the end user but at the cost of the business means I don't get a pay check. This is why it is essential for senior and above UX designers to have an understanding of the business. You can begin by trying to understand these questions:

• Why does the business want this product?
• What priority does this product have amongst other work?
• Is this product meant to generate revenue, or reduce the cost of doing business?
• What impact does this product have on the business' quarterly plan or future?

Knowing these answers can help you make decisions on the kind of user experience journeys. Low business impact products might not need or require the full UX treatment. That week of research and understanding user pain points isn't worth it to the business if you are just creating a product to align with a government requirement, for example. On the other hand, if the product you are working on is a key component of that quarter's business objective, then you might want to push for that pre-work UX seminar with all the stakeholders and prospective users. Explain why you need multiple rounds of prototyping and user testing to dial in the experience.

Our business leaders are there to be the advocate for the business. They succeed by:

• Making money (profitability): Bring in more revenue than it costs to operate.
• Get customers: Attract people who want or need what you offer.
• Keep customers: Retain them so they buy again and become loyal.
• Deliver value: Solve a real problem well enough that customers are satisfied and trust you.
• Operate efficiently: Do the above with as little waste, friction, and risk as possible.

The Developer

Understanding your partners on the development side is also essential. Some user experience designers might have started out as front end developers. Some started by learning how to code basic html, css, and javascript (this was my journey). Others don't have as rich of an understanding of code, but that isn't required for a user experience designer. What is required, is knowing what your developer is going through and what their limitations are.

The developer is the advocate for the technology. They can help decide what language to code in, what provides the best security, what technology will expand easiest as the demands grow and the product evolves.

You can have the best product in the world that generates the most money with the best user experience, but if you don't have the technology to make it, you have nothing.

This is the second place I will bend as a user experience designer. Having the best user experience that can't be built or become a reality is no experience at all. Relying on our developer partners to help guide us in what is technically possible is essential.

Our developer partners are the advocate for technology and they succeed by:

• Making things work: Build software that does what it’s supposed to do.
• Make it reliable: Ensure it doesn’t break, crash, or behave unpredictably.
• Make it understandable: Write code that other developers (and future you) can read, maintain, and extend.
• Make it efficient: Use resources wisely: time, memory, performance, and developer effort.
• Make it safe: Avoid bugs, security holes, and data loss.

The Designer

As the designer my goals are the most clear to me. I am an advocate for the end user. The people who are going to use this product. I use empathy and sympathy to try and understand the needs of the user and how they will go about using the product. I want the product to feel intuitive, like something they already know how to use. For the features that are new, I want them to be easily discoverable, and once discovered, repeatable. A highly learnable system after intuitive and discoverable features.

A product should feel trustworthy, efficient and usable.

You can have the most cutting edge technology wrapped around a product that should make you all the money in the world, but if no one can use it, you have nothing.

As the user experience designer and advocate for the end user my goals are always to empathize with the user and make their experience intuitive, discoverable, trustworthy and easy. I succeed by:

• Making it usable: People can figure out how to use it without frustration.
• Make it discoverable: Users find features with ease and delight.
• Make it clear: The interface communicates what’s happening and what to do next.
• Make it efficient: Users can complete tasks with as little effort and time as possible.
• Make it trustworthy: The product feels reliable, predictable, and safe to use.

The Triangle of Product Influence

Here's where things get tricky. The business, developer and designer all have clear goals and every intention to cover all they can, but, where one succeeds, another may fail.

This is where the push and pull of the product journey lives. The designer will advocate for the end-user, the manager will advocate for the business, and the developer will advocate for the technology. Finding the balance of each is what makes a product great.

Let us consider the three personas mentioned above. I shared each with a line toward a direction they were headed in. These directions are not shared most of the time. Starting with the business goal, which I will argue is first because without it, there is no need for development or design, lets place this going from bottom to top. Next we will add the developer goals. This will go from left to right. Finally we will add the designer goals, which will be backward to intuitiveness and go from right to left. Placing these directions in an equal distribution and we get what I call the triangle of product influence (see below).

Before we map a possible product using this chart, I think it is important to highlight how these three forces can actually work against each other.

For example, a business goal of a manager might be to keep the cost of developing a product down. Because of this they do not allow for usability testing and require the developer to use an existing library of components. The business object is raised by saving money, but the designer and developer's goals are reduced due to the choice.

A developer might advocate for a new technology and by extension the great future benefits it could provide. This, however, will take longer to develop and force the designer to create a new design system to align with the new technology. In this example, the developer's goals are extended while the designer and business goals shrink.

As a designer, I might want the full UX toolbox. I start with research, take the time of future stakeholders to conduct interviews, do usability testing, competitive analysis and multiple rounds of prototyping. This slows the development process down and reduces the efficiency of the business at the expense of the designer's goals.

Seeing how each persona's goals affect each other is paramount to being a good product partner.

Finding the Balance

When one goal can have a negative affect on another from a different focus, it can be hard to find the right balance. Here are a few things I have learned from a user experience designer point of view that try and help get closer to a fuller more balanced product and advancing everyone's goals.

Know the business objectives: As I mentioned above, knowing the products intended business outcome is essential. This will help you find room in the schedule, make a case if there is time for research, competitive analysis, or if the product has lessor weight than others for the quarter.

Speak early with development: Knowing how your product is going to be made can also assist you. If there is a pre-made library of components, make sure you try and reuse these components as much as possible in your design. The product may have a requirement the library doesn't have yet. Talking with development to see what is possible will also help you avoid designing the impossible.

Ask your business manager about the timeline: Once you know the business objectives of the product and how it aligns with that quarter's overall goals, you can ask your business manager for the time you need to research ahead. If development can move their timeline by a week or so, you can use that time to conduct a competitive analysis or stakeholder interview. Use the data you gather to inform your design and back it up with the results.

Advocate for yourself: Even today some of the techniques we use as designers aren't always known by our partners. Explain what can be gained by doing competitive analysis, user interviews, usability testing, or even injecting a spike in the agile process.

Know when to bend to your product partners: Being a staunch advocate for the end-user might get your foot in the door as a UX designer, but knowing when you bend will show your experience and wisdom. Remember if it doesn't make business sense, you don't get a paycheck, and if it isn't something that is technically possible, you don't have a product.

Finally communication goes a long way in general. Remember that even if your role is pushing you in one direction, you all are working toward the same outcome. A product that is easy to use, maintain, and completes a business objective!

If you enjoyed this perspective on the product designer, developer and business relationship, see some of the other articles I've written about my journey with artificial intelligence or how I translate user experience success metrics into business goals. If you'd like to see some of the work I've done in my career check out my work section.

Happy new year everyone, hope you are going into February still holding on to those new year resolutions.