When I get an offer to join a product team, I spend the following days or even weeks considering many different parameters. I see it as a really important decision, which will greatly affect my life.

The first thing I usually consider is the vision — the company’s long-term mission. The second thing is usually the team — the personality, ambition and skills of my future partners.

The third most important thing for me when considering an offer is my short-term missions — the KPIs for each sprint or quarter. What drives the team? What can the team achieve in the following year that would mean success? What does the team discuss the most in the internal meetings? And how does it all align with my personal goals and ambition?

I found it interesting that most teams are very different in the way they work and think. Each team evaluates short-term success differently. I’ve decided to do a small break-down of the characteristics of each type of team, to help myself and others make better choices in the future.

1. User-Centered Team

A user-centered team is a team who puts its users above all other KPIs. User Experience Design is a major value in the company. A lot of time and effort is put into coming up with the solutions that will be the most delightful for the users. The team is very aware of its users, their needs, their pain points, and most of the team’s “fuel” is used to improve the overall satisfaction and make the users love the product more. New features are carefully examined, and only added if they bring enough value to the users.

Examples: Medium, Duolingo

Pros: Good user satisfaction may help with word-of-mouth growth and retention.

Cons: When working this way, success is sometimes hard to measure. Even if many users love the product, it doesn’t mean that the product is profitable, and it may eventually shut down because of that.

2. Growth-Centered Team

A growth-centered team is a team who’s looking mostly on numbers. The open sprint meetings will talk a lot about terms like Acquisition, Conversion, Engagement and Retention. The roadmap prioritises tasks with higher chances to impact the numbers, and not necessarily the best things for the users. It could be done by improving the product and adding value, but also by adding promotions, push notifications, and in the some cases even dark patterns. The employees are rewarded mostly according to their success in making an impact on the numbers.

Examples: Booking.com, LinkedIn

Pros: If the company succeeds to grow, the new resources could help with hiring talented employees and it will assist with building better products and moving fast in a later stage.

Cons: User satisfaction could decrease, and it will make it easier for a more user-focused competitor to take over the market.

3. Features-Centered Team

A features centered team is a team who has many new ideas it wants to build. The roadmap has deadlines for each feature, and the team’s focus is on shipping the discussed feature on time. The features usually come from users’ requests, stakeholders’ demands, or the sales team that wants specific features to use as a selling point.

Examples: Wix, Atlassian

Pros: Adding features may help the sales team bring a new audience.

Cons: Having many features may take away from the product’s usability. Also, when the team is always working on new features, it may forget about improving other aspects of the product.

4. Design-Centered Team

A design-centered team is a team who prioritises the beauty and the luxury of its product above everything else. Its focus is on shipping impressive products. The designers are highly regarded, and spend a lot of time researching, ideating and sketching.

Examples: Apple, Nike

Pros: The users could turn into power users, or ‘fans’, and become very loyal to all current & future releases by the company.

Cons: Good design is often not cheap. If the mass does not adopt the design — the company may fail. Also, beauty may come at the expense of usability, which will decrease the user satisfaction.

5. Technology-Centered Team

A technology-centered team is a team focused mostly on improving and maintaining the technology of the company. It could spend a lot of time on refactoring the code, fixing bugs, switching to a better framework and sometimes on researching, and pushing the boundaries of new technologies.

Examples: Amazon, Google AI

Pros: Fast and stable products can lead to better user satisfaction. Also, sometimes these companies help change the world.

Cons: Spending a lot of time on writing better code for simple products who are ‘good enough’ could slow down the team.

6. The Naive Team

A naive product team is a team working on a product or a feature without a clear short-term KPI. Someone brought up an idea that was adopted by the team, and now people are working on making it work. Not much time is spent on research, design or development. It is often a common practice for validating ideas, or for a team who can allow itself to work on creative things without a clear goal in mind.

Examples: hackathon projects, early stage startups

Pros: The team can be creative and move faster. The idea can bring value to many – and can be monetized and improved in later stages.

Cons: The result could be something that people don’t need, or be a low quality product that will need rethinking in the future.

What else can we do better?

We designers, have the chance to make an impact if we take responsibility for what we put out in the world. Small and daily decisions will add a minor drop to the ocean, but will make a big difference in the long run. And if all of us will design with a human-centred approach in mind, we can create better products that may have an impact. So here are five thoughts on what we can do better about the user experience of our products:

1. Create a classic, not a bestseller

Creating a great product is a marathon, not a sprint. The extra time dedicated to research, improvements, polishing the details, testing, editing will make a big difference. In the long run, companies who did cut corners will slowly become obsolete or easily replaced and people will forget about them.

It starts by wanting to create a classic — Robert Greene

Take the construction on La Sagrada Família in Barcelona, which broke ground in 1882 yet whose completion is slated for 2026 — the hundred-year anniversary of the architect’s death. The months and years and decades fall away.

It took decades for Apple to achieve a market cap as today. Edison’s famous line that he failed 10,000 times before he found the perfect solution for his lightbulb. And this type of innovation takes time and effort and it can’t be rushed. Otherwise you will get a messy and clunky end product.

Alan Cooper recently wrote that the value of design should be obvious to everyone in the organization. If someone is asking you to explain design’s value, it’s because they can’t see it. He said:

“If your boss is asking you to quantify the value of your work, you need to understand that your work indeed has no value. Not at that company. Not with that boss.”

That was harsh. Alan goes on to suggest there are only two alternatives for this situation:

“So when your boss asks you “What is the value of your work?” you have only two valid courses of action: 1) Accept that you and your situation are a valueless combination; or B)[sic] Go some place where your work is valued. Go somewhere that doesn’t ask the value of your work, but instead values your work!”

For me, this hit home. Back in 2011, I said something very similar. After explaining a couple ways to get stakeholder to start investing in UX, I suggest:

“…maybe it’s time for you to find someplace else to work. Someplace where the executives are already convinced and want to make the investment.”

“Go Somewhere Else” Is Privilege Talking

It’s been years since I originally wrote that. I now realize that’s a very privileged point-of-view. Not everyone is in a position to switch up jobs and move to a new job where the management appreciates design more.

While the demand for designers is currently the highest it’s ever been, it’s not evenly distributed. There are places where designers struggle to find opportunities. Walking away from their current job, no matter how unappreciated, may not be an option.

Alan’s recent post reminded me we need to talk about viable alternatives for those who need to stay where they are. It’s unfair for Alan or me — two middle-aged white dudes — to tell others finding a new job is their only option.

Not All Design Work Has Value

I think Alan is correct when he says some design work produces no value. A designer could feel that just by tweaking colors, cleaning up typography, or making a set of screens look consistent, they are making a design better.

But just making a design feel better doesn’t mean it’s more valuable to the customer or user. It may be designing for design’s sake.

That said, I don’t think Alan is correct when he suggests that when someone is questioning the value of design, it’s always because the design work has no value. It might be because the value hasn’t been discovered. Not all value is obvious.

Not All Valuable Design Work Is Of Equal Value

The value that comes from good design is incremental. Thousands of small decisions, thoughtfully made, with a focus on the users’ experience is what makes design valuable.

Not all design decisions have the same value. For example, in the initial release of a recent new design tool, the design team didn’t include a way to store work files in folders. Every designer’s files needed to be in the same collection with everyone else’s, with no way to divide up the work by project or design portion. This wasn’t an issue for small projects, but designers using the tool for large projects found the missing folder functionality frustrating.

In user interviews, no designer would tell you that folder support is a feature they’d pay extra for. Yet, when it was left out, it devalued the design tool. Several of their early adopters gave up using the tool because they couldn’t make it work well for their projects.

Someone on the product team decided to leave that functionality out. There’s any number of reason why that might have happened.

They might’ve run out of time or decided it wasn’t necessary. It might not have been part of a bigger decision to focus on the design-related functionality and not the file storage capability. Maybe they didn’t think of it at all.

By leaving out the folder functionality, they missed a basic expectation for many of their users. Adding it back in is valuable. Is it as valuable as, for example, a feature that could cut hours out of building animations? Not all valuable design work is of equal value.

In UX Design, ROI Is Often About Eliminating Poor Design

Return on investment isn’t as complicated as everyone makes it out to be. It can feel difficult to calculate, but that’s because we often look in the wrong places. Not because it requires some fancy financial wizardry.

For UX Design, ROI is about finding an improvement to the organization’s bottom line. (“Bottom line” refers to the design of a Profit and Loss Sheet, a standard finance tool where the organization lists all of the money coming in and all the money going out over a time period. The bottom line is the report’s last line, where we subtract the total expenses from the total income. When we improve the bottom line, we’re making the organization more profitable.)

The obvious place designers go when trying to calculate the bottom line is to ask the question, If I change the design, how much more income could we generate? But there’s another way design can help: reducing the costs.

A much-overlooked portion of design’s value is that poor design is very costly to an organization. Poor design generates costly support calls. It causes lost sales or dropped subscriptions. Poor design can increase development costs through rework and waste.

When we start looking for where poor design hurts our organization, we can talk about how much money we’d save. We make it easier to calculate the return to our investment for making better design decisions. (If this intrigues you, I wrote more about this in A Proven Method For Showing The Value of Good UX.)

Design Leaders Know Poor Design’s Cost To Their Organization

This is why I disagree when Alan says your design has no value if your boss asks you about it. I believe your boss might be asking you about the value of design because they think of you as a potential design leader.

If you are reading this, it’s very likely you either are a design leader or will become one soon. One responsibility of a design leader is to demonstrate the value of design to the organization.

It’s likely your boss wants to help you make the products or services better but hasn’t learned how to describe it’s value yet. They’re looking to you to help make that case. They’re looking for you to be the leader your organization needs.

A design leader is ready when their organization comes asking about value. That means researching where poor design costs your organization money.

If it’s a big enough amount of money, you don’t even need precise numbers. Sometimes, it’s good enough to just point to large pain the organization is feeling.

For example, say you get many support calls because the design doesn’t do something the users expect. That’s a high cost due to a poor design decision. If it’s easy, you could ballpark a number. (Number of calls x average support call cost.) You may not need the math if everyone agrees that’s likely expensive. High value doesn’t always need to be quantified; it just needs to be seen.

Design Leaders Promote The Value of Good Design

A design leader finds where poor design is costing the organization money and pain. They start documenting it and put together ideas around what the design team could do differently to reduce those costs.

When the boss comes to ask, the design leader will be ready with answers for them. They can tell their boss which poor designs cost their organization and how they believe they could fix it.

Good ROI happens when the cost of fixing a problem is less than the ongoing costs of letting the problem continue. By having a ready plan, they’ll have the perfect starting point to discuss the ROI of design.

However, here’s the trick: smart design leaders don’t wait until their boss asks them. Smart design leaders are pointing out costs and how good design would reduce them before their boss even thinks to ask. When they can, smart design leaders start decreasing costs without being asked at all.

Smart design leaders prove the value of good design in advance of being asked. Their bosses don’t ask what design’s value is, because they already see why the organization should invest in it. They’ll know why they are investing in the design leader.

Smart design leaders aren’t in the position Alan describes, where their only options are to stay somewhere that doesn’t understand the value or leave for another place that does. They’re right where they should be. Providing value to their organization by doing the right thing.

Originally published on UIE.com