Mayra is a Product Design Manager at Pivotal Labs SF where she helps startups and enterprises transform their culture and grow their user-centered, lean product development processes. As a manager, she also supports the growth and development of the Pivotal design practice. Mayra was also featured in a recent InVision fireside chat on the designer/developer relationship.

Eli: Mayra Vega, design manager at Pivotal Labs, thanks so much for being on Conversations on DesignBetter.Co.

Mayra: Thanks for having me.

Eli: Before we started recording, we were chatting that you went through the Product Design program at Stanford. I went through it as well almost 20 years ago now. How do you feel that background—it’s technically a mechanical engineering degree with a strong emphasis on the design process and design thinking, and used to include studio design and art classes—helps you empathize with the engineers you work with, as a design manager?

Mayra: Basically, I feel that maybe it didn’t align that much. Like you said, it was very mechanical engineering focused; you’re required to take some CS course work, and honestly, I wish I had taken that sooner so I could have had more knowledge about that. But I just took one class. It was pretty cool.

It does give you some context, very baseline of, “This is what it means to code,” because at the time I started, I was like, “I have no idea what this is.” I think there are definitely things from the course that I reference. Outside of school though, I ended up doing my own sort of course, online coursework and JavaScript and CSS, just to get some of the foundation there because as designers, we’re expected to know at least a bit more on the front end, maybe not so much back end. So I think that all helps me understand some of the constraints developers think about, gives me a starting point for a conversation. And at least we’re kind of speaking, to some extent, the same language.

Eli: This may not have been true across the board, but  I certainly noticed this whole spectrum of engineering talent within the Product Design program. For folks like me who were more attracted to the art and design side of the program, I felt that just being on teams with very engineering-minded people, learning the lingo a little bit, helped me along the way in my career. Just understanding that personality made it easier to interact with engineers later in my career.

Mayra: I can see that.

Eli: Just to set the stage a little bit, we had you on Fireside Chat recently talking about the designer/developer relationship. I’m wondering if you have any other insights to share around what it looks like when a design team works effectively with a product engineering team and maybe any areas where things can go horribly wrong, or even just slightly wrong.

Mayra: In terms of working effectively, it helps to have a good understanding of what all the disciplines bring to the table and what we’re trying to achieve. And, like you said, having empathy for where a developer is coming from. In these meetings, where we’re talking and going through the backlog together, and saying, “Does this story make sense? Do you, as the developer, understand this for our users and why we’re doing it?” And then for me to understand those follow-up questions they have. Sometimes I’ll miss, for example, an edge case that I didn’t think about, because they have to think about all these details, right? The more I sit in those meetings, the more I’m able to think about ahead of time.

The more we have an understanding of each other, the better. And also, we start off in the same place, so that we’re both focused on the same goals. I talked a little bit about, sometimes engineering, at least one engineer will start a project, and go interview users so they also have an understanding of where I’m coming from as a designer, and what I’m trying to achieve with designs. We’ve had some conversations about this here, amongst various teams, and I think that’s one of the things that came up, throughout different engineering teams. How much they value being able to put input into design and be a part of that, because it’s like, “Oh that fully grounds how I do my work. How I think about approaching the development of it.”

So those are just some thoughts on how we work effectively together. Just so we make sure we understand both sides.

Eli: And how about where could things go wrong?

Mayra: There can be a difficult balance sometimes staying ahead of development.

---

As a designer you want to look far ahead of things like a holistic system, but you also don’t want to be too far, where you’re building on top of assumptions.

Mayra Vega

Pivotal Labs

As a designer you want to look far ahead of things like a holistic system, but you also don’t want to be too far, where you’re building on top of assumptions.

So here at Pivotal, we try to stay about two weeks ahead of development. It’s easier said than done. Sometimes it’s hard and you want don’t want to get too far, and sometimes you actually fall behind. For example, a design didn’t test very well. All of a sudden you’re like, “Oh shoot! I have to redesign this, and now dev is catching up to me.”

So trying to keep that balance can be kind of difficult. But, to the extent that we can, we try to make sure that we’re not going way too far the other end. Maybe that means that our design is getting really far ahead, then we may want a new development peer to join the unit.

Eli: In the Fireside Chat you mentioned that a lot of the work you do at Pivotal is with larger companies like Ford, where the structure may be that the engineering teams (often called IT) sit apart from the design teams. So it’s not the kind of typical cross-functional set up you might see in a more tech oriented company. What’s some of the guidance you give to those larger companies, in how to maybe start organizing teams, or take steps towards better designer/developer partnerships.

Mayra: We usually try to start small. Change is difficult, so if you can start at a small scale, I think that’s really helpful. Usually when we’re working with big clients, we’ll say, “Let’s do one project together. Let’s see how that goes.” It’s working the model we propose. They come on site with us, work in types of teams that we work in. “Here, let me show you the value of working this way, and then you can see if this is something you want to continue and go from there.”

One of the challenges I’ve seen of some large organizations is sometimes you have the split between IT, and that’s kind of where the development team sits, and then you have a marketing team, and sometimes UI sits there. And the people that come to us asking for help on process, seems to be the IT side. So they’d say, “Come help us with this development team.” We’re like, “That’s great you have developers. You’re excited to change. But it’s not just the one development, it’s about the whole balanced team. So let’s see how we can bring your designers in.”

So there’s some stakeholder management in the line that’s bringing in… whoever is in charge of UX at that organization, for them to be brought into this mission as well. We do various workshops with the stakeholders to talk about, “Where do you see yourself. What are the challenges you face?” Acknowledging those challenges, makes you talk more about how to really bridge those gaps.

A lot of that is often this idea that, design sits somewhere else and they’re just tossing over designs. Then they complain that, “My designs aren’t implemented the way I expected.” Well you can expect that when the teams aren’t communicating as much, right? So we try to show them doing a project together can address some of those challenges they acknowledge they are facing, as well.

Eli: You mentioned alignment, and on Fireside Chat again, you and James Ferguson discussed a little bit about design sprints. What are some of the tools you use to get stakeholders involved early in the design process?

Mayra: One of the things I mentioned was these kick-off meetings that we have every time a project starts. Sometimes, even in the middle of a project that seems to be veering off course, we’ll go, “Alright, let’s all get back together and make sure we’re on the same page.” We emphasize a lot to the stakeholder team, that it’s really important for them to attend. Basically we’ll hold this meeting and we’ll pause until you guys can all make it … ideally. In person, sometimes that doesn’t work out.

We have a very structured format for kickoffs: Let’s all get on the same page about what the goals are, and then we can duke it out. We realize that an IT stakeholder had one thought about what the goal is, but marketing stakeholder a different goal. So then they could refine what that means and we have somebody that will sell it to you and say, “Okay, what are you really trying to accomplish. Let’s dig deeper. How can we make this a goal that has a metric tied to it. How will we make sure we reach success.”

---

For me, what’s probably one of the most important parts of the kickoff meeting is alignment on goals. Once you have goals, you can figure out how to reach that afterwards on your own.

Mayra Vega

Pivotal Labs

For me, what’s probably one of the most important parts of the kickoff meeting is alignment on goals. Once you have goals, you can figure out how to reach that afterwards on your own.

There is also talk about making sure we’re aligned on who we think our user is. As you go through the format of this meeting, you start identifying all these assumptions that they’re making. They’re keeping track of that, “Oh, it sounds like you think this. How competent do you feel in that?” And they say, “Well, I’m not quite sure. There was a research study done two years ago.” And I’m like, “Hm, maybe we should re-validate that.”

So we keep an outline of that going and at the end, we tend to wrap up the risk, where everybody, even the working team has an opportunity to think about, “Everything we’ve talked about today, what are some of the risks that we’re taking?” It could be based on team and structure, but it’s also, “What are the riskiest assumptions that weren’t in here?” The product is to put it on this being the user and none of this is really a need for them, so we haven’t really validated that. I may identify that, that’s kind of what we kick-off a project with, and we immediately start trying to go validate those risky assumptions, making sure they have mitigation for the other things like a stakeholder that’s going to back us up on the type of process we want to follow.

Eli: So in essence, you’re using a lot of your design and design thinking training to establish that framework, because you’re doing user research on the stakeholders, challenging assumptions, and kind of reframing the problem, and then it sounds like you’re trying to identify this area of risk. Then you go out and to validate you build prototypes, you get feedback. How do you feel about the validation part?

Mayra: I think it depends on the sense of what the assumptions are and where we are at in the space. With some teams it’s like, “Oh, we have to do ethnographic research. Let’s go study people out in the field.” And your team can see that and report it back to the stakeholders and say, “Here’s what we learned. We went to observe these people.”

Sometimes it’s a little more validated and it’s maybe more the concept. So in that case, we’ll do, “How can we test this concept in a really minimal way?” So instead of these experiments, we have a lean hypothesis. And say, “We think the problem is this. And if we give something this tool, this is the outcome we expect to see.” So we’ll go take it out into the field and test that.

One example recently was, one of our clients wanted to create an app for sandwich ordering. This is a grocery store chain. So we’re like, “Let’s make sure that that is validated that your users really want that, or would they rather use an existing tool?” So we went into the experiment with email registration and click through rates, and I’d just be like, “Is this concept something that resonates with these people?” And I got to know some people that were standing in line at the sandwich shop at the grocery store, and then realized that, no, of all the people we registered, a few clicked on it, then no one registered. So I knew it wasn’t quite the best thing to focus on. Let’s go figure out what’s actually appealing to them.

Eli: That’s great. So, are there any drawbacks from cross-functional teams?

Mayra: I think the biggest thing is about building in a design culture. And getting to learn from each other. We work in pairs. We work with a pair that’s a Pivotal and a client designer, so we can enable them in the process. So we don’t get to work with each other as often unless we bring on a second pair of designers.

---

Sometimes the challenge to fostering cross-functional culture is that unless you’re intentional about building that culture, it’s not necessarily going to happen organically if the teams are all distributed.

Mayra Vega

Pivotal Labs

Sometimes the challenge to fostering cross-functional culture is that unless you’re intentional about building that culture, it’s not necessarily going to happen organically if the teams are all distributed.

Because you sit on your team and you go to lunch with them, and you’re so embedded. You’re trying to work on this product right, that unless you have that time to step out of that and say, “Let’s meet together and have a critique…”

I’ve worked in various offices throughout Pivotal, and I’ve seen a variance to what extent we hold to those, kind of, traditions and rituals that we should have as a design team. I think here, recently, we’re say, “Let’s be really intentional. We’re not going to skip crit no matter what. Even if no one has something to present, we’re going to show up and we’re gonna talk about design. Some way or another, let’s make sure that we’re always meeting on a regular key days to share learning. Just have that space to talk about design beyond what’s immediately needed in our projects.”

Eli: That’s great. Anything else you wanted to talk about?

Mayra: One thing was kind of about people talking about handoff and what handoff looks like. Given my experience at my past company, where it was me redlining a lot, and writing a bunch of comments on my mocks, so that I could send things over… the process now just feels so much better. I work with product managers. Sometimes we pair to talk about how a story should communicate the intention of the design. So that’s a great way for us to make sure thatI don’t have to be there redlining and putting the comments in my mocks. It’s in the story, so it should be part of that process.

I found that to be really effective and just having those meetings where we prepare the stories over a cross-functional team, so we’re all on the same page about what’s actually being delivered. The design intention is there. Business intention is there. Part of the development team, they get all the details that they need. So that every unit is something of value that can be released to the users. So I found that really effective. There are a lot more tools now that do some of the redlining and details for you, so that helps a ton.

Eli: What books or blogs or podcasts are you finding helpful in your role right now?

Mayra: I follow Sidebar.io, so I get my daily five links a day. In on our design channels here at Pivotal, people find things and they’ll post relevant stuff.

Eli: And is there anyone who’s been a mentor to you along the way, that helped you get where you are today?

Mayra: My first manager, here at Pivotal, was really helpful, Abby Sturges. She’s no longer at Pivotal, but I think she was really helpful, helping me think about management from a designer perspective and just applying a basic design mindset to everything you do. I think one of the biggest things she told me is, “When you’re working with clients, you think of them as users as well. Your service is a product to some extent, so what are their needs? And the more you think of that, the better you can be at consulting.”

Also, tying that to how you work with your team. So we also think about how we have retros every week, where we figure out what’s going wrong on our team. How can we restructure? What can we do to make how we work more effective? And that’s, kind of, a way to solicit, “What are our needs as a team? How can we find a good solution this fit?” So I think she was just a very mindful person, and I appreciate that that she brought to the table.

One more person is another Pivotal employee, Kim Dowd. She did a lot in terms of teaching us all sorts of different methods. She had a massive toolbox of things to try. She just went around doing workshops with different teams and just making sure we were all trained up on these different things and had the opportunity to practice methods that we weren’t familiar with, or don’t use every day, but every once in a while. The more you build your toolbox, the more you have stuff to pull from. The various crazy situations you might find yourself in as you’re trying to build a product.

Eli: That’s great. It’s always nice to have good mentors that help you climb that ladder. Thanks so much, Mayra, for being on Conversations.

Mayra: Thanks for having me. It was fun.