Inside Design: Yesware

Yesware is an email productivity service that helps salespeople make more money. Since launching a beta version in 2011 with just 10 employees, they’ve grown to a 70-person company with over 300,000 customers—including the sales teams at Groupon, Outbrain, IBM, and eBay.

We’re so proud to have Yesware as part of the InVision community. We sat down with Yesware Product Designers Eileen Ani and Beverly Achterhof to find out more about their agile process, workplace empowerment, and the importance of defining success before you start designing.

How’s the product design team set up at Yesware?

Eileen: The product design team is made up of 3 product designers, and each of us works with one of our 3 product development teams—they’re all independent units and consist of 4 or 5 engineers and a product manager.

Each product development team has a different focus that might shift from one quarter to the next, but for the most part stays the same. For example, one team is working on our Outlook product, another is currently working on a new feature for our Gmail product, and the third team is working on reporting.

I meet regularly with the 2 other product designers to do critiques, sync up on ongoing project work, and talk about anything we need help with.

Having small teams working on different products helps increase speed and collaboration. Our goal is to always move fast and iterate quickly.

Have the teams been set up this way from the beginning?

Eileen: It’s something that’s grown over time. When I first started here 3 years ago, we were a 10-person organization focused more on engineering than design. There was an all hands on deck approach to get things out the door back then—we all generally worked on one project at a time.

Now we’re a 70-person company. Since we’ve grown, we’ve realized that it’s not efficient to have everybody working on the same project at once. We’ve also realized that you sacrifice quality in design and engineering when you have the same person covering both roles.

Beverly: A big shift happened about a year and a half ago when I came on at Yesware. I was hired solely as a designer onto what was then our mobile team, which worked on iOS. I was the first designer here who wasn’t expected to code.

Seeing how that worked out set the expectation that this is a perfectly reasonable thing to do, and our other designers were able to make that shift over time. And when we moved from a strict Scrum engineering way of doing things to more of a custom agile development process, it really opened up designers to focus on design.

Can you tell us more about why you switched to an agile process?

Eileen: Before, we were having a tough time taking on bigger projects and making that fit into the sprint schedule we were following at the time—it was really limiting to say something had to fit into a 2-week sprint. I think that’s partially because we weren’t being flexible enough in terms of how we tackled Scrum, but we got to the point where we needed a shakeup to allow us to do things outside of the sprint schedule so we could tackle bigger projects instead of just making small, incremental changes all the time—especially as design got a stronger voice at Yesware.

Do all of the teams follow the same agile process?

Eileen: It’s different with each team, though we’re all agile with the same values. Each team comes together to talk about the overarching schedule.

Beverly: The dynamic between the designer and the product manager is different on each team. Some teams have a more junior designer with a very senior product manager, while other teams are more evenly matched in that regard.

Eileen: All of the teams are committed to frequent releases—on average, we push releases every day.

Do the 3 of you sit together, or do you sit with your specialty teams?

Beverly: I’m in the San Francisco office, so I don’t get to sit with the designers or my team because they’re all scattered. Half of them are in Boston, and many are in Europe.

Still, we chat a lot online and have regular video meetings.

Eileen: I’m one of 2 designers here in Boston. We sit together, but we’re not far from the engineers we work with.

What’s the design culture like at Yesware, especially with one designer who’s across the country?

Beverly: When design was able to break off from engineering, we were really able to focus and grow our design culture. We started meeting more regularly, with a standing daily critique that we use any time someone needs feedback from the other designers, and regular collaboration across projects.

We’re the only department in the company that’s talking cross-team on a regular basis. We’ve also tried to be more vocal in business strategy meetings by talking to all of the product managers and making sure we’re representing design to the best of our ability.

Eileen: The 3 of us have a supportive environment and offer each other design therapy on a regular basis. We’ve developed a really good atmosphere around that.

Do you have any advice for people who work with remote employees?

Beverly: I’ve spent a lot of time hanging out in Boston at our headquarters to get to know everybody. My best advice is to make sure you have open communication with your team. That means having communication tools in place, like instant messaging, video conferencing software, and even InVision to get quick feedback on mockups and prototypes.

Eileen: We try to make it a priority to include people who are working remotely. During meetings where three-quarters of the team’s in the same room together, it’s tough for the remote people people to speak up and be a part of the conversation. We make an effort to turn to the remote worker to ask for their input, and we pause long enough to allow that communication to come through. Otherwise, it’s just not a productive environment for remote workers.

How do you collaborate with other departments at Yesware?

Eileen: We meet regularly to do planning, standups, retros—a little bit from Scrum and a little bit from Kanban. Designers and product managers usually have one-on-ones on a regular basis, too.

Beverly: All of the designers and all of the product managers try to meet once a week as well. We found that because the designers were meeting so regularly, cross-team issues were getting resolved much faster. So we started getting designers and PMs in the room together to talk about bigger product design issues and where the company is headed as a whole.

What’s the most powerful part of your design process?

Eileen: With larger projects, we’ll do a sketch session, which is where we put a bunch of different people—designers, engineers, a product manager—in a room together for a couple hours.

We outline the problem at hand, talk about what we’re trying to do, and figure out the business goals and design goals. Everyone sketches ideas for how to tackle the problem, and then we go around and talk about the sketches. This encourages buy-in from everybody involved in the product from an early stage.

What are some of the values you try to see reflected in design changes?

Eileen: We have a couple of goals around cohesiveness across the product, along with clarity and simplicity. As a design team, we’ve learned that we’re successful when the product goals are well defined. We work hard to make sure that’s provided when we start a project so that we can produce designs that are simple, clear, and usable.

What does a typical day for you at Yesware look like?

Beverly: Most days, the design team is sheltered from having too many meetings, other than our regular sync-ups with each other. But at the beginning of a quarter, things are totally different—we do lots of planning. Because we don’t have an executive design representative, the designers are able to be a part of bigger business strategy meetings quarterly and talk about the product road map.

After that, it gets taken down to the team level—stakeholders, the designer, and the PM represent their team and try to solidify that road map for when it goes to the development team.

From there, the designer, PM, and engineers try to figure out what we’re going to work on for the next 3 months. This creates a couple of weeks of some really intense meeting time. We’re fortunate to be able to go heads down and crank out designs with just regular checkins with the people who need to be looking at them.

From idea to launch, what does your process look like?

Eileen: For a really big project where we’re just trying to do exploratory stuff, we start with research and interviewing customers. Then comes sketching, wireframes, and getting feedback without getting too bogged down with the details of what the feature is actually going to look like.

With smaller projects, we start with a sketch session. We don’t tend to get great feedback from customers using wireframes, so we usually have things that are more high fidelity—even if it’s just a prototype where we’re trying to validate a basic idea. We’ll make a few different prototypes and test out the feature at a high-fidelity level.

And this is one place we’ll use InVision—we’ll do a video call with our customers or meet them in person, and they’ll click through the InVision prototype as we ask them questions and get validation on ideas or direction going forward.

Next, we’ll hone in on one idea and make some high-fidelity mockups. We’ll work with the development team to oversee implementation and offer them any help we can.

Do you have a specific process for design handoffs?

Eileen: Generally, the engineers are aware of the project before they see the final design. When the final design is ready, we’ll bring it to a planning meeting with the whole team and talk about it. The engineers will likely have questions, and we’ll probably wind up making some changes. It’s not really a handoff—it’s more of a collaboration.

As the engineers start developing the final design, we’re still with them every day.

We’ll frequently provide redlines halfway into the project to help clarify the visual details going on. We’re also there to answer questions about interactivity or anything else that comes up.

How do you think your design process differs from other companies?

Beverly: I have friends in this space who are part of much bigger companies than Yesware. I hear a lot about their process and how there’s a lot more delineation between designing and engineering, and they’re not necessarily embedded in the team like we are.

The nice thing about the way we’re set up is that it allows us to be more agile, and we have much more control over the end result because we get to be next to them every step of the way during implementation.

In that sense, I think there are so many pros to working on a smaller team. Plus, we have more ownership than what we’d have on a larger team.

Because we don’t have the mentorship a bigger team might have, we have to seek out learning opportunities and push each other to grow.

Eileen: Another difference is that at many companies, they might have a different design team set up with more specialized people: someone who just does wireframes, someone who just does visual, and someone who just does research.

Here, we each do a little bit of all of those things, so we get to know our projects inside and out. Getting a deep sense of intimacy with your designs is a good thing.

How do you make design decisions internally?

Beverly: Each person leads on their own projects, and then they get input from the other designers. Because each of us knows that product so well, we have the strongest sense of what we’re trying to accomplish with it.

There’s a lot of feedback around—especially with visual design—keeping the Yesware brand strong. We like to get feedback from other designers on that. As far as the larger design strategy of Yesware, it’s really up to the 3 of us to get together and really own that.

What tools do you use to document your collaboration?

Beverly: We all work out of a shared Google Drive folder, so we have access to each other’s working files. We have a shared style guide that everyone’s contributed to—it’s always in progress.

How do you use InVision during your design process?

Eileen: We use InVision to make clickable prototypes that we put in front of customers to get early feedback on feature ideas.

We also use InVision to give developers access to implementation documentation. For example, my team has a link to the InVision file for the project we’re working on right now just pinned to our Slack room. Every new iteration, or every new piece I add to that, just goes into that InVision file. The developers constantly check it for information, like how to lay things out.

InVision’s great for internal feedback. It’s easy to put something in InVision and then set up a link out to stakeholders or anybody in the company who wants to have access to it like sales executives, and have a quick way for them to look at in-progress projects to see what’s going on.

Eileen: Getting feedback in person is always great, but I find that even when I’ve gotten feedback in person, later I’ll suddenly see comments popping up in my InVision file.

How do you stay creative and engaged while working on the same brand?

Eileen: If you have a high degree of intimacy with the product you’re designing, you’ll stay engaged.

And when you have a deep understanding of your customers and how they use your product, you feel strongly about making improvements. You want your customers to be happy and enjoy using your product.

We have a high degree of investment, so we all feel responsible for what we’re working on. Plus, we have the flexibility, in terms of the projects we do, to challenge the style guide or contribute to the larger vision in some way.

Do you have any best practices or suggestions for companies that are re-imagining a really specific user experience?

Beverly: Get to know your user to figure out where their daily pain points are and get a good sense of how they were doing it before your app came along. See what their hacks were and what their day-to-day was like.

To get to know our users, we started with email tracking. We’ve since grown our feature set significantly, but you have to find that major pain point and start by solving that really well—and then see what else you can solve for your users. Always keep your users in mind.

Eileen: Never assume you know the answer right off the bat.

Present yourself with a problem, not an answer, and then let yourself explore all the possible answers you can think of.

What’s your user base like, and how has it changed since you launched?

Beverly: They’re not shy.

Eileen: When we were much smaller, our customers were likely to be early adopters and much more adventurous in terms of tools and software they’d try out. Now we have a lot of bigger companies as our customers, so it’s a different type of person to work with.

Beverly: Our target is salespeople—they tend to be chattier and more willing to engage with people, especially if they have a concern. We get regular feedback from them, and many of them are willing to participate in usability tests and look at new things we’re working on. It makes our jobs easier to be able to have those kinds of users.

How do you keep up with changing web standards and opinions on what good design is?

Beverly: In the last year or so, we’ve been given room to prioritize that to a much bigger extent than we were before. When we were doing Scrum, there was a big focus on making the MVP features our focus. We never knew if or when we’d get to come back and iterate on that.

And now, as a design team, we’ve spoken up and said our design needs to be at a certain standard. We’ve been able to step up our game in terms of what’s acceptable as a baseline.

Yesware encourages learning by sending us to design conferences and supporting us taking time to educate ourselves on what those standards are and what we’re individually capable of. If you don’t take time to keep learning, you’re going to fall behind.

Do you think that differentiating your UX and visual design will help you compete more effectively against current and future competition?

Beverly: By presenting a high-quality level of brand design, we build trust with our customers. They expect not only a high level of visual quality, but reliability in the product’s ease of use. That kind of level of quality attracts new people to the brand—and then it helps them stick around.

What role do you think designers should play in developing business strategy?

Eileen: Designers should be included in business strategy conversations—design is such an important viewpoint to articulate at that level.

We as designers have all of these strategies we use to come up with solutions—whether it’s for user interface problems or a problem in the physical world—and all of that is translatable to strategy decisions. If your business encompasses designers, you should add their voice to the table to make sure they can succeed, and help the business succeed.

What do you think is the difference between a product and a feature?

Beverly: Sometimes I think we talk about products when we almost mean platforms. Yesware is the product, and we want that consistency of experience, features, and ease of use across any platform our user might be on. As we add new platforms, we want to make sure the product itself remains consistent and that all of the features are equally available and easy to use.

How can you tell when you’ve created a good experience?

Eileen: When people use your product again and again because they enjoy it and it’s making their lives easier, you’ve created a good experience.

What does success in a design project look like for you?

Eileen: When we start a project, we try to define what success looks like before we’ve even done it. Success should be defined upfront so you can realize what your design is trying to accomplish.

Do you have any advice for new designers?

Beverly: Try things. Try to learn as much as you can. Try new software. Absorb as much knowledge as possible about what you can do, and then practice—either with freelance projects, side projects on your own, or an internship or entry-level job.

You’re never going to get good at design unless you work at it.

Eileen: Don’t be afraid of feedback. I’ve had to learn that the success of a project or a design doesn’t begin and end with me—there are many people involved. The only way to reach success is to get feedback from people involved in the project, and then incorporate that feedback when you iterate.

Photos by Kim Indresano Photography.