Evangelizing UX at a Growing Company

Jonathan Haines at UXDX Community: Empathetic UX: Merging Gamified Research and Social Responsibility. Video: https://youtu.be/4K-UB2BVLbg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Designing at a growing company

[00:00:00] My name is Jonathan Haines, and I am from Brooklyn, New York, the second American in a row. I've been in the technology space for around a decade or so, most of which has been in some sort of design capacity. I've worked with bigger companies and smaller companies. At the moment I'm at a startup, so I'm wearing many different types of hats. I'm doing a lot of research, but then also visual design, some implementing, testing as well. And it's a very different type of company to be at, because you're trying to figure out the best way to advance the company's lifespan moving forward.

[00:00:41] What my company does: it's a property technology company, and it digitizes data and speeds up the process for multifamily renovations. So it is dealing with houses and apartments, and taking that data and improving these properties. What I'm going to be talking about today is the great challenge of designing at a growing company. A growing company could be anything from a startup; it could be a 10-person company, it could be a 30- to 50-person company that's just making some advances in terms of headcount and trying to figure out its next step.

[00:01:25] Companies experience growing pains at all times. I think it's very difficult for a company to go from a small company to a large company and not experience any issues. And at the same time, we are definitely in an environment that is not friendly towards job seekers, but also towards people that are currently in a role that they like. Layoffs are happening a lot. And unfortunately, once you do get the role, there's this growing challenge of trying to remain relevant in that job, because there are a lot of applicants coming looking for your role. So how can we remain relevant in a design-related position, knowing this?

Good design is invisible

[00:02:11] Why is this even a topic for a designer? Well, design, as we may know, is something that you don't really notice until something is very wrong. This web page right here is purposely designed very poorly, and because it's purposely designed the way it is, it brings your attention to it. When things are designed right, it's very easy to miss the design, because great design, when done well, is invisible, as mentioned by Jared Spool. You want to be as invisible as possible, but you also want to let people know that you are the person responsible for the good work that you're doing: the good research, the good visual design, the testing, whatever kind of data you're providing.

[00:03:14] When you're not doing the job right, it is noticeable, and when you're doing the job right, it may be invisible. So a lot of what this talk is about is going through tips on remaining relevant and making sure that people are aware of what you're doing, so that it could foolproof you at this growing company.

[00:03:33] What do others think that we do? This is very much a joke, but at the same time, to a certain extent, there is a conglomerate of people out there that think that a designer is a person that is making some pictures. They're drawing stuff; they are pixel pushers, if you will. This is simplifying design in a huge way. Obviously, as we heard from the previous two talks, there's a lot of research that goes into design. There's also a lot of testing. There's also a lot of management of design systems, and creating variables and components, and everything that goes into style guides and branding. So design is definitely not something that can be simplified, as we see in the picture, to drawing some pictures.

[00:04:26] But at the same time, from the outside in, if design looks very simple, this is what it could look like. Design can seem seamless, and the work that goes into things like design systems could be completely missed. So if you are just doing your good work and that's it, it actually isn't enough. You need to be on people's minds, and you need to let people know that you exist. A phrase that I have heard in describing remaining relevant in your current position or your job is that a closed mouth does not get fed.

[00:05:05] It means that if you are just doing your work and staying quiet, it's very likely that people aren't aware of what you're doing. It doesn't exactly mean to boast about all your accomplishments, but at the same time, you do want to let people know that you are responsible for the good work that goes into XYZ. And this remains true even for people that you don't interact with, people on different teams, for example. If you are only staying in your lane, staying in your silo and only dealing with your product manager, or maybe your developers, then there's a whole sales team that doesn't know about your work, or there's a whole customer success team that doesn't know about your work. So do as much as you can to remain on their minds as well, so they know that you are the go-to person for your expertise, whether it be research, visual design or whatever it is.

Why companies don't hire UX early

[00:06:02] Let's back up a little bit and talk about UX as a whole. Why exactly is UX important? We probably all know why UX is important, because this is our livelihood; this is the line of work that we have chosen to pursue. But in a 10-year span, the value of a company goes up if they have a design focus, a UX focus, if they're making sure that they are planning for longevity, as opposed to a very short-term sprint and just doing feature bloating or something along those lines. So companies that do hire designers early, or focus on UX early, tend to do a little bit better, as you can see from this chart.

[00:06:52] But at the same time, this is in a 10-year span. In 10 years, a company can go out of business. Five years is way too long, and one year may be too long for certain companies. So even though design does represent a long-term solution, it also depends on how much patience your investors or the C-suite people at your company, the CEO, CTO, whoever it is, have to wait for this 10-year span for the fruits of what you're putting in place to really take effect.

[00:07:31] Why don't companies hire UXers early? We talked a little bit about it in the last slide, but there are other reasons. If you haven't seen this Venn diagram, I think it's something that in startup life is extremely relevant all the time. The way it works is there are three separate circles: you have the good circle, the fast circle and the cheap circle, red, green and blue, and you can only choose two of these circles. If you are a really good company, a unicorn company, sometimes you can choose three, but it's definitely increasingly hard. So a lot of times the company is forced to choose two of these three.

[00:08:13] And unfortunately, the two that they usually choose are that things have to be fast, because there's no patience for waiting for that 10-year growth, and things have to be cheap, because growing companies, new companies, may not have the funding to pay for something at a premium. Investors many times want to see tangible results early, so they choose something fast. And even if they are going from seed to Series A to Series B to Series C, it only gives you a certain amount of money to play with, and there's a lot of growth that happens with the company. So sometimes that means that they can't spend top dollar on a UX designer, because they would much rather spend it somewhere else. Why is that? Because, as we mentioned, good designers may seem a little bit more invisible than we'd like.

[00:09:11] What is the cost of UX? Well, growing companies need to feel fast, and research and design take time to iterate. So not only are you paying in dollars, but you're also paying in time. This is what the curve looks like. The red curve is how the requirements look from when a company starts: if they don't take care of changes early on, the cost of those changes goes up drastically, as you can see on the right side of this chart. However, on the left side, if we take care of design very early, and we handle the information architecture, we handle the design system, we handle all of those hard things up front, it really pays dividends a little bit later on.

[00:10:02] Because then you're not wasting the time of the developers, you're not wasting time getting the exact UI right. So it does save time, it does save money. But as we mentioned before, this stuff takes time, and a lot of times a company, especially a growing company, doesn't really have the time to wait for that.

Short-term thinkers and the agile hydra

[00:10:20] Now we'll talk a little bit about human psychology. This is an older graph, but I do still like it. It's a graph that shows fitness centers, I believe it's UX-centric, but it's relevant for pretty much anywhere, I would say. What it's saying is that in January of the year, people usually tend to really like to go to the gym and really focus on their fitness, because January is a time of new beginnings. It's the time to say, "It's a new me, new you," whatever it is, and put your front foot forward and really make an effort to change something that you wanted to change about yourself from the year prior.

[00:11:18] Usually what happens is new customers start in January, but as you can see, by February there's already a dip. Planet Fitness is just one example; it's the most drastic example. Once we get into February, the new customers start waning, because it's no longer January; they're no longer new customers. This also happens in May and June, as you can see here. Equinox is a little bit more high-end of a gym, and what we see happen is people start going to Equinox once the summer is approaching, because they want to have the best body possible. But that too wanes, as far as new customers go, because it's no longer something that's super relevant to them as the summer moves on.

[00:12:05] What does this mean exactly? Well, human beings are a little bit more wired to be short-term thinkers. Unfortunately, the way that we evolved over time, millions of years ago, was to be focused on surviving the day, as opposed to planning for a 401(k). So long-term is great, but it's very hard to conceptualize. An example of this would be an experiment called the one cookie now or two cookies later experiment. It's usually done on children; I don't know if it's still prevalent these days. A child is given one cookie and the adult leaves the room, and the child is told that they could have one of these cookies now, or if they wait five minutes they could have two cookies instead of one.

[00:12:55] And instead of waiting for the cookie to double to two cookies, a lot of the children can't wait, and they just have one cookie. That is with children, but unfortunately it still is relevant for adults. Adults also tend to not know how to plan for the future, as opposed to just being short-term thinkers.

[00:13:21] The agile hydra. I have a little bit of a delay. The development process usually follows this sort of process: we have the PMs that lead to the designers, and the designers give their designs to developers. Usually what this means is that these three different factions are supposed to work together. The PM is supposed to set where you're supposed to go, what you're supposed to implement, where you're supposed to be in the next sprint or so. The designer is supposed to take those plans and put them into something visual. And then the developer is supposed to take the blueprint set by the designer and turn that into a construction, building a house, if you will.

[00:14:19] That is how it's supposed to be. It's supposed to look a little bit like this, like a fierce hydra, where all three heads of the hydra are running on all cylinders and really demonstrating power all over the place. However, because of this issue where design is invisible and design takes too much time to really show the fruits of its labor, maybe not a lot of times, but sometimes, companies can end up looking a little bit more like this, where the PMs and the developers are showing physical things, while the designer is unable to show something as concrete as what the developer or the PM is able to do.

[00:15:09] So what we can do is plan tactics to show that designers are not just pixel pushers, that we actually solve problems. And just one more time, remember that design is a long-term solution. Now what we're going to do is talk about a few different tactics that we can go through in showing the rest of the company that designers are problem solvers, and that we can do more than just color pictures and push pixels.

Know the right people and showcase design

[00:15:44] The first tactic would be to know the right people. If you have an org chart, if you know who your manager is, but also your PM's manager, your developers' manager, if you know all aspects of how a company looks from an org chart perspective, it's important to have an audience with anyone that you can find relevant to design. If you get buy-in with the right kinds of people, they will always look to you as the expert in the design field. And that's what you want to do: you want to be the person that they think of when they need something design-related.

[00:16:30] There's also a concept called eat the frog, which means that you want to do the thing that your manager doesn't want to do. This doesn't necessarily have to be your manager, but one example would be, let's say the CEO doesn't like to own a certain meeting or something like that. If you take that meeting from him and then you run it your own way, that's one way of eating the frog. It's just taking something that is [audio drops] displeasures [?] in touch.

[00:17:18] Whether you work remotely or work in the office, there are ways to showcase what design is doing, and this is one of those ways of doing it. This could be through Gchat or Teams or whatever you use; Slack is another one of these tools. What you want to do is, if your company has something like all-hands meetings, or some sort of meeting where the company is getting together, use that as a platform for showing off what design does. If you have a design team, get your design team together and tell everyone: this is what design does, this is what we do, this is the design system we're working on, these are the things that we want to accomplish in the next few months.

[00:18:05] Growing companies especially want to have things like this, because they want to show company unity and they want to showcase that the company is growing. So reach out to whoever is in charge of these sorts of meetings; they probably would be pretty happy to have you. And these are other things that you can talk about: what exactly is design making, what exactly is a design system, and what is the plan for the next year, or the next month even. Go from there; choose your own adventure for what you want to tell.

[00:18:43] And using that meeting, you can catapult it to other endeavors. One of the things that I did with my design team at my current role is we did have one of these meetings, and from there we made a Slack channel called design postbox. The design postbox is a nonsense Slack channel, a fun Slack channel, where people can put their recommendations in, or if they're a little confused with some sort of designs. It's a postbox for the design team to look into things that people are seeing. If your company is way too big, then it probably wouldn't work, but if it is a company that's only, let's say, 30 people, it might be a good way to do that. And you can also do this to showcase milestones or design decisions, maybe if there is an update to the brand guidelines or something along those lines. This is a really good way of doing so.

Internal research, Loom and workshops

[00:19:47] The next thing is internal research. The image on the right side is a value proposition canvas, and it's a really awesome way when you are dealing with any sort of clients, let's say. They are experiencing some sort of problem, they have some pain points, and by using something like a value proposition canvas, you're figuring out a way that you can take those pains that they have and turn them into something positive. By using this value prop canvas, you can turn it into something with your co-workers. So stay in contact with your team and figure out ways of helping them.

[00:20:31] The sales team, for example, are talking to customers a lot. They're probably on the phone with the best customers that you could possibly talk to. So if there is a way that you can talk to those customers, that's great, and if not, then become friends with the sales team and make sure that you are aware of the things that they're hearing on the other end of that phone. That's a really good way of making sure that you're taking care of those pain points.

[00:20:58] Another thing would be the developers. If developers have a hard time deciphering designs, maybe what you need to do is talk to developers and figure out the best way for them to understand how to organize Figma, for example, or if they need, and we'll talk about this in a little bit, a video like a Loom video to explain things. This can be another way of staying in contact with the people around you, to make sure that they are aware of what you're doing.

[00:21:28] As I mentioned, Loom can be another really important way to make sure that you are staying in touch with your co-workers and staying relevant in design. What Loom can do is record you going through a prototype, talking through a design decision, talking through research, for example. These are all ways that the design team can make sure that people are aware of the work that the design team is doing.

[00:22:03] And facilitate workshops regularly. This is something recent: some people that I work with are not designers, and they're still a little unsure of how Figma works. So just having short workshops going through what Figma does, even just the basics of how it works. It doesn't have to be Figma; it could be other tools that we use as well. But walking through how Figma works, how you use Figma as a design team, how you organize files: these are all ways of inviting them into the things that you're doing and making sure that they're aware of how to do the things that you do.

[00:22:52] And just one more time: design is a long-term goal. You're not going to see the benefits of design overnight; this is a long-term thing. However, if it is long-term, that's okay, because there are strategies that you can put into place day by day to let people know that there are things that you can be doing, so that people are aware of what the design team can be doing. And that's it. Thank you so much. These are just a few of the links to find me, if you want to connect with me on LinkedIn, or I have a design-related Instagram as well if you want to follow that. And I'm sorry about the microphone, by the way.

Q&A

[00:23:40] Host: No problem at all. Thank you very much, Jonathan, that was really interesting. The value of UX and design research and design is so continuous, but it's great to always think of different ways that it can be tackled and improved. So thank you for sharing.

[00:23:59] Jonathan: Awesome, thank you so much.

[00:24:01] Host: Excellent. If anybody has any questions, please do comment. Shelby has noted, around eating the frog, that it used to be about tackling the hardest problem of your day first so that you have capacity for the others, like the big rock, little rock metaphor. But she thinks the other approach, of taking on your manager's job as well, is a good way of looking at it.

[00:24:29] Great. One of the things, and I am intimately familiar with the challenges of trying to sell the value of doing research and design up front, because there is the bias towards just building and just getting something out the door. What I always think is that unless it's linked to a manager's KPI, they're putting their neck on the line to trust you. And that's a dangerous game to play, because it just needs one change of manager and then all your good work is gone. So are there any KPIs that you're aware of, so you can say to your manager, "This will improve your KPI," so it can be a bit more tangible and hopefully less subject to change just as one person leaves?

[00:25:26] Jonathan: That's a good question. I think that's the goal: you want to back up what you're doing with data. Because if you're not, then it's, "Well, how do we know that in 10 years or five years or whatever it is, this is actually going to work?" Something that I'm trying to do now is implement better testing for our products. It's a relatively small user base, so testing is not as important, because you can't get as many insights. But at the same time, it's more important, because you can see so much more as something grows. Even just a small sample size: this is where we were one week, and this is where we are the next week.

[00:26:19] Taking it apart from a manager's KPI and just having it as the product's KPI, even. When things are attached to a manager, it can be great for the amount of time that that manager is around and relevant and whatnot. But once that manager leaves the company or gets transferred to a different department, that could really leave you in a bad spot. So having either multiple managers' KPIs, or attaching the success of what you're doing to the product itself and backing it up with data, that's really the best strategy, I would say. But there are definitely others as well.

[00:27:03] Host: Yeah, I think it's a good idea to have a little bit of a backup, because I have unfortunately seen it go backwards in more than one company when a champion leaves or moves on, as you said, and then the new person is more about delivery, delivery, delivery. So it can be a bit challenging. I think that's all of the questions that I have, but I just wanted to thank you once again for sharing. I thought that was really insightful, and thanks to all of our speakers for sharing.

[00:27:36] Jonathan: Thank you so much for having me.