Translating Design Goals to Business Needs

part II of Finance for Designers

hello!

Last week I shared part one of how I address the Top Five Complaints from my friends in Design, taking on the first two of these five common complaints. This week we're going to tackle the remaining three.

1. Everyone only cares about finance.

2. I keep getting asked to drop everything to hack together one deal.

3. No one takes me seriously when I bring up real user problems.

4. People just want me to push pixels.

5. I don't get brought into the process early enough.

I covered the finance that's helpful to know as a designer (Valuations, Discounted Cash Flows, Multiples, Revenue, Average Contract value, and Sales compensation). I also recommend it for engineers, PMs, or anyone else who wants to understand a little bit more about finance and go to market! This will make the most sense if you get the initial financial context, so if you didn't read it probably good to start there and then come back.

This week also has a skew towards early/growth software startups, and while it was originally written with designers in mind, a lot of these ideas will overlap for engineers and other technical contributors. The intent here is to help designers be more effective, so this focuses more on things that are controllable by designers vs. ways business stakeholders might be better.

Fixing "real" user problems

As mentioned last week, leaders think of "good design" as something that is accounted for in future revenue projections. But even with that, designers will find themselves facing specific projects that don't align with their sense of good work. I'm using "exec" as a business stakeholder here, but it could easily be someone specific on the team who isn’t an executive.

One example is the idea of "default to subscription" within a payment flow. Executives sometimes love it - "it'll increase subscription revenue," which clearly would increase ARR.

This results in a conversation along the lines of:

Executive (trying to make the business succeed) - "I want you to make a flow that opts users into the subscription!"

Designer (trying to be helpful and share expertise) - "We shouldn't do that! It's unethical! It's bad design!"

Executive (just got called unethical, no longer feels warm and fuzzy about designer) - "Just do it."

Designer (feels ignored and not valued) - Does it and is super annoyed or quits.

I picked this one arbitrarily, but you'll see a ton of examples of things that come up like this on the Deceptive Design site (the site has been around for a long time, they were formerly called Dark Patterns). There are also lesser versions of a similar conversation - maybe it's not about ethics, but it's still "not up to our standard" or something else that has a sense of absolute good for the designer. Either way, everyone feels bad, and there's not much traction for starting a conversation on alternatives.

Switching language can help a lot:

Executive - "I want you to make a flow that opts users into the subscription!"

Designer - "So we're looking to increase subscriptions?"

Executive - "yes!"

Designer - "I have some great ideas for this"

This is a lot less controversial and helps to broaden the conversation to ways to increase subscriptions vs. one solution. It keeps you on the same team. The designer either can bring up ways to increase the metric, or could also broaden to ways that the design proposed might negatively impact other business metrics. Designers tend to already have this skill from matching user language (like from user interviews or in product copy).

For instance the designer might be able to work from one of these:

1. I don’t want the user to buy something by mistake and return it -or- That user won’t ever purchase again if they're opted in, even if they would have been a repeat buyer. (good if there's solid data on different sets of purchasing behaviors).

2. I don’t want the user to have to call into service and spend a ton of time trying to fix their mistake (good for when companies are spending a lot on support and there is another key metric around support).

3. That user doesn’t really want the product and might leave a bad review (good for when there's a high NPS/referral rate that needs to be protected).

Whichever way the designer decides to have the conversation, it will go further when it's aligned to the underlying model the exec has in their head for which numbers matter. Sometimes a PM can be a great partner to help convince other stakeholders or tell you which metrics would be most convincing.

If you want to translate this model to engineering, one of the most common complaints is "we're always building new features instead of solving technical debt and tooling." Most non-engineering executives don't directly care about nebulous technical debt or "clean code," but do care about things like "fixing this would reduce production incidents for our customers" and "if we invest 2 weeks now, every feature in this part of the codebase will probably take about half the time it's currently taking."

To be the best advocate for my perspective, I have to translate user problems into a language execs understand.

Pixel Pushing

Another one that comes up a lot from designers is "people just want me to push pixels, that's not what the hard part of design is." (I'm going to generalize here - there are obviously pure UX designers, but for the most part designers do also have visual skills, especially the ones who are making this complaint. This is also different for larger teams that start to split creative/brand from product).

For people who do have this problem, it's a design specific version of "what got you here won't get you there."

Within design teams it's very common to see people progress from having a smaller project to larger ones with more complex user experiences and flows. It's well understood that everyone on the design team has some sense of visual acuity. Visual design is also likely to be something in the "zone of excellence" (concept from 15 Commitments of Conscious Leadership) - something that doesn't feel hard to you because you have so much practice over time, but that's true across the design team. I haven't been there, but I could see how emphasizing your more abstract skills would help with getting better projects and promotions.

On the other hand, some of those more abstract skills may be embodied within other people in the team. Frankly, even if they aren't as good as a designer would be, those skills don't feel as "unapproachable" to other teammates as visual design does. Many people can draw on a whiteboard, but that's not something you can ship.

Saying "visual design is the easy part" to a team of non-designers ends up coming across as either

1. Implying everyone on your team who can't is an idiot

2. Acting like you shouldn't have to do something because it isn’t fun or challenging for you

As a parallel, most Product Managers do not love: scheduling meetings, sending status emails, or other forms of endless project management. No one on the PM team is saying to their colleagues "wow! great job scheduling! you should get promoted." You just have to do it. It's a piece of work they pick up as a trade for the other interesting things they get to do, but most good PMs don’t complain about it to the rest of the team.

Another parallel is that engineers pretty much never say "I don't want to write code" even though the most senior engineers spend far more time on people problems and architecture (more on staff engineering).

"You took the fun/hard part of my job and let me with this easy thing!" - not so convincing to your coworkers.

"For our visuals to have the most impact, they really need to interact with the overall experience, for example remember how much better feature X’s design was when Designer got to work on it upfront?" - far more convincing.

Rather than thinking about it as something to push down, I'd think about it as a competitive advantage. The designer is the only one who can do the visual design that will allow the product to get out the door. It's a unique skill - instead of downplaying it, use it as a starting point to advocate for other work that will help it be even more valuable.

I don't get brought into the process early enough

I think these are the top three reasons I've seen keep designers out of a decision making room:

• Too busy on something higher pri

• Not focused on the important thing during the discussion / a distraction

• Don't want them there because of some sort of interpersonal tension

If you've been reading this post and the last one and you buy into it, there's already four things changes I hope helped resolve these:

1. A better sense of the quarterly priorities and key customers

2. Fewer interruptions for “last minute” deals 

3. Less time spent arguing and less emotional tension with stakeholders

4. Owning the power of being able to do visual design instead of talking down about it

If you're still not in a room after that, it's worth asking for extremely direct feedback. I'd aim to absorb that feedback the same way you would in a crit - it's about your work in the meeting room, not about you as a person.

It's entirely possible you will hear that your past contributions weren't valuable, or that the team still sees you as having other higher priorities. If it's not one of the two mentioned above, some other reasons that nothing to do with you might be: there's already too many people in the room, there's too much overlap in skillset with other teammates in the room, or this just isn't a job where that's going to happen. It's better to know and decide if that means you want to work at a job where that is going to happen! If you can't get the direct feedback, that might be another warning sign.

---

I hope this two-part series provides actionable ways designers can apply the skills they already have to common complaints, and reframe them.

And you already have the tools you already have that can help you do this:

• Finance is the context that helps you align and empathize with all of your coworkers.

• Use interviewing skills to understand why a project is “urgent.”

• Align your language to get the most buy in.

• Own the power of being the only person who can do visual design.

• If you still aren’t in the room, ask for direct feedback.