Inside Design: Treehouse

Founded in 2013, Treehouse set out to offer kids and adults all over the world an affordable way to learn how to code. The online interactive education platform has a library of over 1,000 videos that teach everything from business to web design, and students put their new knowledge to the test through quizzes and code challenges.

Their dedication to education and great design makes us so proud to have them as part of the InVision community.

We sat down with Treehouse Product Designer Klare Frank to discuss collaborating with remote teams, the value of designers knowing how to code, and designing for success.

How’s the product team set up at Treehouse?

We have 9 designers, and 2 of them manage teams made up of designers and developers. They help facilitate some of the larger design team things, like leading meetings and setting goals.

When I first joined Treehouse, we were a completely flat organization with no managers. We assigned projects when someone came up with an idea that others in the organization thought was something we should work on.

After a while, we decided we needed more direction and focus. So that’s why we now have a couple of team managers.

Do you have a particular kind of team structure you use?

It depends on the composition of the smaller design and development teams, but the way I work isn’t necessarily dictated and processed by the design team overall. Right now I’m on a team with one developer, and we may have another developer join our team in a few weeks. The team structure really depends on the people I work with on a daily basis.

What’s the mix of designers on the team like?

Every designer at Treehouse has some sort of visual design knowledge—we can all draw up illustrations, and we all know HTML and CSS.

It’s great that we all have a T-shaped skill set—broad across a certain set of design skills with a specialization in one thing. Somebody might be much stronger at mobile design or illustration, or somebody might be amazing at Ruby on Rails.

What do you think about your team structure makes it successful?

We have a couple of managers guiding the design team and making sure that we’re bettering ourselves as a team. But at the same time we’re flexible enough and we respect each other enough that nobody’s really dictating what we do or telling us a certain way to do things.

There’s a mutual respect here because we’re all good at our jobs. We need that collaboration between one another as equals.

Tell me a bit about the design culture at Treehouse.

All of the designers work remotely. We communicate entirely online with Hipchat, and we have a weekly meeting over Google Hangouts where we share whatever we’ve been working on and provide feedback in real time.

Throughout the week, if we’re working on something we need feedback on, we just ask on Hipchat. And if it’s something in the early stages of design, we’ll start an InVision project and leave lots of comments about how we see things eventually working, or ideas for interactions on the page.

Why do you think having that kind of design culture is important to your team?

It’s important that you set an expectation for having open communication between designers. You should encourage people to share their work often, because when you’re working remotely, you can get siloed easily—you can become focused on your own world because you aren’t in an office with other people. You aren’t going to walk by somebody’s desk and ask what they’re working on.

You have to be more open with the things that you’re working on so that people know how your brand evolves over time and the things that can spark ideas in their own projects.

What’s the biggest challenge you face as a team?

Our structure changes all the time, and recently we’ve started to add team managers and really define our goals, and we even hired a VP of Product. That’s all challenging because it requires flexibility and the expectation that if something isn’t working, it’s probably going to change in our organization in some way, but that it’s probably for the best. And if that doesn’t work, then we’ll find something that does.

Do you have any insights for those facing similar challenges in the workplace or any tips and tricks that have worked really well for your team?

Open communication is essential. If your organization is going to change something, they need to let everybody know exactly what’s going to change or what they’re proposing to change.

How do you work effectively with other teams in your organization?

For the past few months, I’ve been working on the jobs team at Treehouse, which is focused on getting people job-ready. For example, someone might want to become a Rails developer. They can go through a track on Rails and be able to build out Rails projects, but that might not necessarily provide them with enough skills in order to get a career out of it.

On the jobs team, we’ve been working on providing that extra set of skills and that extra help in order to get people to not only book interviews, but ace them thanks to being able to provide great sample work.

Within the jobs team, the designers and developers collaborate with each other. If I come up with a great idea for a new feature, I’ll create an outline that shows the design changes and then share it with the design team in order to get feedback.

There are different sets of teams within Treehouse besides the jobs team: the marketing team works on the front-facing website, the education team works on most of what goes on within Treehouse itself, and then there are other smaller teams like the mobile team, which is working on a few review apps.

But within those teams, it’s the different job titles that interact—you aren’t necessarily interacting much with somebody on a different team unless you have some sort of crossover. In that situation, it’s really easy to just talk to another designer who’s working on another team.

What do you consider to be the most powerful part of your design process?

The ideation process. Being able to start with a program and come up with an idea of how you might solve that problem and get enough feedback from your own team? That’s powerful.

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

I want my designs to help a student get a job, or to help them understand whatever they’re trying to do better. I’m thinking about those goals throughout my entire design process—it might be embodied in something like simplicity, but that’s just a subset of trying to help students learn better.

What’s a typical day like for someone on the Treehouse design team?

It’s different for all the designers, but I usually start my day with a checklist of things to work on. Tasks might be tied to starting a new project, like working on a sitemap or user flow. I might even work on CSS in order to make things look better—everybody’s CSS winds up bloated after a while, and it annoys front-end developers at every organization. So I’m typically working on everything from visual design to solving UX problems, to front-end dev work.

Can you run me through your design process on new features?

Within the jobs team, we usually discuss feature ideas for a while, and then I try to come up with some ideas for how I think the feature might get implemented. For some features, I might end up creating a user flow if it’s more complicated because it helps me think through problems a lot more and visualize the different screens on a page and how a user might go through something like that.

Since we already have such a huge code base for all of our different visual elements within the app, I usually just go in and I start coding. I don’t have to worry too much about how it’ll look, because it’s already within our brand and I can refine that later. I just want all the elements that I think that should go into that new feature that I want on the page.

From there, I might take a screenshot and put that in InVision so I can start moving things around and share it with my design team to get their ideas. After that, I often go back and refine it, show the jobs team, and then share it with the developer to get his thoughts about how he thinks it might work.

Can you tell me a little bit more about your hand off to development?

Since I code the front end, the hand off happens through Github. I’ll point the developer to the branch I started, and he’ll take a look at it and will often add great things to it that I wasn’t even expecting.

If you don’t know how to code, be sure to communicate a lot with your developer and tell them exactly how you see things working.

How do you think your design process is different from other apps in your space?

Designers at Treehouse tend to do a lot of different things besides just visual design—we span everything from ideation of projects to front-end coding.

How do you identify and prioritize feature requests?

You can’t possibly add in everything that everybody wants. Since we’re bringing in new heads of departments and a VP of Product, we’re starting to identify more features and drill down more into things that we should be doing in order to be more successful, rather than just things we might like to do. And that’s much different than how it was when we were a flat organization.

It’s important to tie feature requests to your organization’s goals.

How do you make design decisions as a team?

On the design team, we respect each other because we’re all good designers with the best intentions for the work we do. The most important thing that we do is just give really good feedback on the work that we’re doing throughout the entire process.

What kind of metrics are you guys watching when you’re making design changes?

We try watching lots of different metrics like:

• How often someone logs in
• What times a day someone logs in
• What courses someone’s completing
• How often someone’s completing courses
• When people decide to pause subscriptions

Even when we were a flat organization, we tied our projects to those specific metrics and what we wanted them to change. That’s still the same today: we want to lace a specific goal on a specific metric like that in order to be able to judge whether a project is successful.

Designers often measure success by asking if they solved a problem, but they forget that a problem can have many solutions. And even if they did solve that problem, is it the best solution for their specific goal? More designers should consider those.

Do you find that having those metrics and making data-driven choices is really beneficial to your design process?

I think it can inhibit if you focus on metrics too early or early enough in the process. But for the most part, it’s just something I keep in mind whenever I’m designing. So if I’m working on a specific feature of a project, I might change that feature because of that specific goal.

How do you use InVision as part of design process at Treehouse?

We use InVision to present just about any type of work that isn’t about to go off into production. Whenever we have design team meetings, we’ll put what we’re working on into InVision and send the link out.

If one person wants to comment on it in Hangouts and someone else also wants to say something, they don’t have to wait until somebody’s done—they can just type in their comments right there. Using InVision to communicate and collaborate has been key for us.

How does your team collaborate with one another, especially with the remote aspect?

It’s important to know what your team members are working on. Since nobody’s telling me what to do, I want to always make sure I’m getting the right kind of feedback from all of the other designers. Seasoned designers know that showing your work often and getting as much feedback as you can is really powerful.

Do you have a formal review process?

Our formal review process is basically in Github. If we’re going to do a pull request on something, then we have a review process out of that. But I find it’s easier if you have little reviews throughout your design process, because when you get to that one point you don’t want to have all these huge things that come up and have to change everything or delay the project.

Do you have any kind of stakeholder review?

Our stakeholders are usually the team managers, the ones defining what sort of projects we should be working on or what sort of direction we should go in as a smaller team. Since I’m reviewing things with them pretty regularly, the stakeholder review process just happens naturally as collaboration and communication happen.

Do you guys do any kind of documentation outside of Github and InVision?

We have an extensive style guide full of all of our components for both the marketing side and the internal application.

That’s the biggest documentation process. I might also create a whole sitemap of the career program in general and document out which projects are currently being worked on and which ones have most recently been worked on, just so that if somebody takes over my project, they’ll know pretty easily exactly where we’re at.

When do you guys get involved with new feature development?

Early on. Historically at Treehouse, designers were the ones coming up with features. We moved away from that and had more of a product manager role, but we’re still involved early on in the feature making process.

How do you stay creative and engaged while you’re working on the same set of core functionality?

I always thought when I was working in client services at an agency that I would get really bored working on the same set of visual things over and over again, but I really haven’t at all.

Once you understand a system, especially a design system and how it’s implemented, you can let it evolve over time or make small improvements. Those specific points are interesting creative spots where you can evolve in entire organization’s design, brand, or philosophy while still staying inside of it.

Do you have any best practices you can share about designing a product that turns a paradigm on its head?

I’ve run into a lot of designers who don’t want to learn how to code. But having coding knowledge is so helpful.

Some designers don’t like doing it, and that’s fine because they understand that they need to work more closely with their developers. But others get really scared about it and think that it’s too hard or that they don’t have the time to do it or understand it, which is odd because designers should always be trying new things out and learning new processes.

So when you design, are you trying to take some of that fear away

I think people who go to Treehouse have already made that first step—they’ve realized that they want to start learning. But they can still feel kind of intimidated.

Everything we do has to help people understand that you can do it. There have been plenty of people who’ve done it, and so can you.

What’s your user base like and how have you seen it change since you started at Treehouse?

Our user base is broad and consists of:

• Adults who want to switch careers
• People who are already in the field and want to learn a new skill
• Kids who want to start learning how to code

Early on, we definitely had a push for a more kid-friendly atmosphere. Recently, we narrowed the field down to focus on teaching a few skills well and helping people who are switching careers.

It helps to narrow your focus, because if you’re focusing on a lot of things it’s tough to design for a very broad spectrum of people and hit every single thing. But if you design for a more specific audience, it’s easier to hit specific metrics on how their success is going to be.

How are you guys creatively monetizing your product without being gross?

As a brand, we try to be as friendly as possible. We realize that we’re not pushing people onto a product—we want people to come to us with a willingness to learn. If somebody doesn’t want to learn, then why even market to them?

We try to make it easy for people who already have that drive to learn something new to sign up quickly so they can start learning.

On our marketing website, we recently added a section to the hero area where you can test out our learning experience and get used to it before you even sign up.

How do you keep up with constantly changing opinions about what good design is?

Web standards won’t ever stop evolving, but the things getting added only make our lives easier. Back in the day, if you were trying to make images for a border radius there were tons of browser compatibilities to worry about—those are the things that we don’t have to think about anymore.

I think coding is only going to get easier—and that’ll make it easier to learn.

Can you tell me a little bit about the visual design for Treehouse and why it is what it is?

As a brand, we want to come off as being friendly and easy, but still legitimate. The field of tech education is new, and there are so many different angles you can take.

People want to know that if they’re going to switch careers, a hiring manager will see they learned to code from Treehouse and know that they’re a great candidate because it’s a legitimate organization that teaches people solid skills.

Do you think that designers should be playing a bigger role in developing business strategies as a whole?

The most successful organizations have had designers playing a role in business strategy. Designers think more closely to the user base of a product, so they can have valuable insights into what sort of things an organization should be focusing their goals on.

When you start a brand-new design project, what’s the very first thing that you do?

The most important thing: understand the problem. After that, you need to set a goal to address the right solution.

What does success look like for a design project as a whole?

It means all of our students are happy and learning properly.

Do you have any insight for newbie designers?

Share your work often—even if you don’t feel like it’s good enough. Getting feedback from other designers will make you a better designer.

Read a lot. If someone suggests a blog or a book to read, go read it.

Photos by Michelle Moore.