Experiment is hiring a Product Designer to change the world of science

Must care deeply about the future, be comfortable with risk, and have listening skills like a freakin’ owl

EDITED JUNE 24, 2014.

This is a Job Portrait—a story about a job opening produced by off-duty journalists. Learn more here. This portrait was crafted by Jackson Solway and commissioned by San Francisco-based Experiment. The interview below was conducted in-person with Denny Luan, an Experiment co-founder. Learn more about Experiment: Homepage; AngelList profile.

Apply to this position by emailing a cover letter and resume to jobs@experiment.com. Read the traditional job description here.

JOB PORTRAITS: You’re hiring a product designer. What kind of background are you hoping this person will have?

DENNY: We’re so small and moving so quickly, we need someone who can do it all. A full-stack designer, basically. From UX research to literature reviews, all the way to illustration and fine art. They’ll need to handle UX wireframes, flows, and maps, and it’d be ideal if we had someone with a deep understanding of core design principles like color theory and typography. These are things we’ve learned a bit ourselves, but we’ll never be experts. I think this will be a hard person to find, but it’s what we need.

The product team includes, from left: George Su, Ryan Lower, and Denny Luan. George and Ryan are engineers; Denny has worn the designer hat since co-founding Experiment two years ago. The company’s desire to hire a designer is driven by Denny. Throughout our conversations in early March, I sensed he was both nervous and excited to hand over the reigns.

Why did you decide to hire for this position, and why now?

We’re hiring a designer because we’re growing, and our next stage requires someone who can design for scale. Design is also our biggest bottleneck, and having a designer will make the biggest impact in our build process.

The person we hire will need to map out how our user-facing functions scale in the same way that an engineer would map out how a backend scales. In the same way as we care about having good science, we also really care about having a thoughtful and well designed product. This is very intentional on our part because, as a company that deals with presenting science, it’s important that we’re pushing the boundaries of the presentation itself.

People think that science is boring and technical and dry, but we’d like to flip that. We want to make it look good, make it engaging, make it functional, and add elements that people don’t normally see or associate with science. This is going to be one of our biggest challenges as we scale and grow.

Can you describe the kind of autonomy this person will have? Everything from where they will be required to exercise personal judgment with the product, to things like working from home.

They’ll be expected to be in our office, though our office is always changing. We often travel to our users to see the science in action. For example, Cindy and I met with a researcher in Costa Rica recently. We don’t really have a remote policy, but we’re pretty flexible.

For decision making, we want to trust our designer’s sense. We try not to appoint people as “leaders,” but we also want this person to be a way better designer than any of us. We don’t have a resdesign planned, but, you know, if we do one then all eyes will be on this person.

We want someone to feel like they have agency, particularly in the areas where we’re not looking. This is always hard to explain, but because Cindy and I are first-time founders, there are areas that are hidden for us. We want someone who can make decisions we didn’t even know were decisions to be made. We want someone who can follow ideas and experiment.

About half the Experiment team gathered for a morning standup on a roof-that-shall-not-be-named.

Just so we’re being clear, some companies have much more defined roles, and for someone who might be used to a more corporate environment, how would you describe this position?

There will be no one telling you what to do! This is totally different from any other clearly defined role. You will not be designing, you know, buttons for a checkout system for a mega-platform, or repeatedly tweaking something small. For this, you will be owning the entire user experience. You’ll be owning everything from how people experience our outreach, to anything we might print, like a poster. You definitely won’t be alone though—when there’s a major task or problem, we solve it as a team.

How will this person know when they’re being successful? Are there numbers or milestones?

I think other positions like engineering usually have their indicators, like throughput or failure rate. There are probably such numbers for having a designer full time, but more importantly, everyone on the team has a certain sense. It’s how much science we change. How much science we fund. The discoveries we unlock. For our engineering, it doesn’t matter how theoretically beautiful our code is; if we aren’t moving the needle on changing science, all that is meaningless.

At the end of the day, the designer will know they’re being successful when they’re seeing real impact through scientific research. Hmm, I know that might sound a bit ambiguous, but when you’re actually in the office with us it’s very easy to tell when we’re solving problems.

Let me rephrase a bit. On this idea of success, can you say something about the company’s key metrics? And how does this role support them?

Our key metrics at this stage are transaction volume, projects launched, and repeat backers. Those are the ones we all track, and we want to understand how they work. Design touches on all of this. It touches on how researchers go about creating projects. It definitely touches on repeat backers—we know we’re having a big impact when people buy into the experience and start supporting many projects. This is all tied into how we make our users feel, and it’s going to be a really big goal of this designer. On transaction volume, we do A/B testing, which the designer will perform using different tools.

For lunch, I walked up the street to an Indian restaurant with Ryan and George. Over various forms of curry, we discussed their experience working with designers in the past. Ryan: “I’ve worked really well with people who are at the practical end of the design spectrum. It’s really helpful when someone can make a webpage and not just a static thing. I don’t mean they need to ship live code, but they need to get the nuance. It’s also important to be able to move fast. It’s annoying when people get attached to designs that aren’t practical and can’t be built.”

At lunch, I asked George what, if anything, has surprised him since joining the company eight months ago. “Our roles are not really broken out,” he said. “We don’t really have titles. I mean, I’m an engineer, but if I have an idea, I can make it happen. It’s great once you’re used to it. When I first joined I knew this in my mind, but it took me being in the office to really realize what that means.”

On the topic of tools, can you describe the tools you use as a team? And the kind of tools you’d anticipate this person using?

Currently we use rapid prototyping tools. We also create structured user studies where we split test things in front of real people. We use analytics tools like Mixpanel. A designer will need to know why all this is important.

Can you give an example of a kind of problem this person will need to address? Maybe something you worked on recently?

One of the things we addressed in the past was how researchers create projects. We did it once and had it working, which was a baseline, but we knew there was the potential to make it a more pleasant experience. It just wasn’t working as effectively as we knew it could. People would start filling out the forms, but then get stuck and never submit. So we wanted to approach it again with a design mindset.

We ended up creating a project creation system that broke out the gigantic form into many sections, and in each section we have tips on the side plus a navigation bar up top that shows your progress. When we did this we had many more projects get submitted and launched, but more importantly, researchers were having a much better experience. They weren’t coming to us with questions—they were coming us wanting to launch as soon as possible. These changes were driven by design, and they’ll be something this designer helps us refine even more.

I interviewed and photographed the Experiment team on their first day working from their new office in San Francisco’s Mission neighborhood. The company’s old office was a live/work space in SOMA, where some team members also lived. The new office is also a live/work space, though fewer team members also call it home.

We got at this a bit earlier, but what aspect of this job will be most satisfying?

The science. That has to be the most satisfying part. On top of this rare, rare person we’re looking for—in addition to being a full stack product designer—we’re also hoping they have a background, or at least a passion, for science. That’s important for us because four people at Experiment have dropped out of grad school to do this. We have that background, and we think that someone who’s building tools for scientists should be one themselves. The science we enable is our way of doing research by proxy, our way of living through these researchers. Every time the researcher wins, every time they get funded, or someone posts a really engaging discovery, it feels like we win.

Oh, this is all really important to know! It’s good we got to this. Let’s get to the nitty gritty now. How many hours per week do you work, and how many would you expect this person to work?

It’s just startup hours. It varies. Some weeks we work a shit-ton and get lost in our work, while some weeks we take a step back and refocus. We ask ourselves if what we’re doing is working, and if there’s a way to do better. It’s less the number of hours you work, but whether you’re solving the problem well and whether you’re using your time to solve problems.

It’d be awesome if we could hire a designer who could do everything in an hour and take the rest of the day off, but the nature of our problem isn’t like that. We’re not solving one button in a giant, amorphous checkout system. We’re solving top-to-bottom problems.

Admittedly, I caught the Experiment team a bit off guard by photographing their new office the day after they moved in. When I showed up at 8am, none of the tables were put together; by the end of the day, the team seemed remarkably settled in. Or maybe everyone was just high on the synchronous 200mpbs internet connection. Oh baby.

Have you talked to candidates yet, and if you have, what are some reasons they haven’t worked out?

We haven’t brought in anyone yet, but from past experience, we know that one of the most important things about being a designer is exceptional listening skills. That might be equally important as whatever experience someone brings to the table. I think design really is a listening problem. You need to understand the core goal and what the constraints are, and designers who have ideas before they arrive at the table, those are designers who don’t really work out.

On the other hand, sometimes a really good designer will preemptively solve a problem even before getting to pixels or mockups. They might get feedback on a problem, and then realize there’s something else at the root of it, and then they’ll solve that instead.

What kind of salary are you offering? Will you compensate this person in other ways?

Everyone on the team works here for way more reasons than money, but we’re also excited that we’re in a position to be competitive with some larger companies. We offer everyone a package of salary and equity, and the numbers interact with each other. For salary, our range is $80,000-$100,000, but I think we’re drawn to people who are excited to take a bet on us as a company. We’ll lean towards people who are interested in taking more equity and a lower salary, but I know it’s important to have options.

After lunch, Cindy showed Denny a sketch of an idea. By all appearences, Denny concentrated so hard he collapsed into a monitor. The office environment is refreshingly casual. Shoes are rarely worn, naps are regularly had, and the team feels as close to a family as any I’ve met.

Can you summarize why Experiment matters?

Experiment is important because we’re solving a really big problem for scientists. Right now, many scientists have no one to turn to for support. The current science funding system is full of problems, and what’d we’d really like to do is establish another reality, another way for doing science. We want to help scientists who have risky ideas, or who are young, to do things that otherwise aren’t allowed today. As long as we’re helping these ideas that wouldn’t otherwise be funded, we’re succeeding.

Even if Experiment died tomorrow, we’d be really happy knowing that we’ve helped so many ideas get off the ground. But Experiment won’t ever die. This idea has to exist. The ability for someone to connect with science they care about on a very individual basis, to enable that, it has to exist. Even if we go broke, I’ll figure out a way to get Experiment on a server in my mom’s garage. That’s how important this idea is.

How would you advise people to prepare for interviewing?

Be passionate, be ready to learn, and care about the problems. There are definitely things you can do in that first conversation to show that you’ve been passionate about past ideas, or passionate about the future. There should be things that genuinely excite you. Have something to show that has pushed you beyond your comfort zone.

Also, if you can come to us with three things that could be improved about some obscure flow that you think we’ve neglected, that’d be really cool. And remember, you need to care about the science! It’s one thing to solve design problems at a cool company and get paid a lot and live in San Francisco. That’s a dream some people have. More important for us is solving problems for scientists. You can only really do that if you understand science, so that designing for a problem feels like doing justice for yourself.

And I was serious about looking for someone who’s a really good listener. I know people put that on a job description—and then rarely get it— but it’s the one thing we’re going to be super sensitive about. It’s something we detect within the first five minutes of talking with people.

Final one. What will the first day on the job look like?

First, we’re going to make you drink…tea! We have these sencha shots that are really great. You should probably expect a buritto eating contest, too. Our new office is in the heart of the Mission, so we’re surrounded by great food. Then we’ll head to the climbing gym and make you lead a 5.12! Or if you can’t, we’ll just go eat another burrito.

Seriously?

Yea!

Apply to this position by emailing a cover letter and resume to jobs@experiment.com. Read the traditional job description here.