We sat down with Kyle Fiedler, Chief Design Officer at thoughtbot, to chat about involving designers in business strategy, hiring the right people, and the one thing teams need to build great software.
How is your team set up?
The design team consists of about 25 designers across the US and Europe. We work alongside roughly 80 web and mobile developers. For each client, we divide into teams that best suit the needs of the client, the problem the client is attempting to solve, and the people who have the problem.
Teams are usually comprised of 2-4 people per project, with about half being designers and half being developers. Some project teams consist of only designers or developers, but we try as much as possible to have both roles represented.
What’s the culture like there?
Collaborative, friendly, and thoughtful. We trust everyone at thoughtbot to do the right thing for them and the company—our primary policy for everyone is, “Use your best judgment.”
We strive to be as transparent as possible. Our company handbook, which contains our benefits, hiring procedure, and other company policies, is hosted in Github. Any employee of thoughtbot can request a change in the way we do business. The vibe is a bit different in each studio based on the personalities of the people and the culture of the city.
“Rely on your team’s experience and knowledge.”
How does your team communicate with each other? And how do you communicate with people on different teams?
We expect everyone on the team and our clients to communicate with respect and thoughtfulness. We expect our work environment to be collaborative, with everyone having an equal say in the business or app and no one taking orders.
We use Slack to communicate in real time across all our studios. Even though most of our teams sit alongside each other, we’ll still talk through Slack to avoid interruptions—and because we have some remote teams.
“Teams have to trust each other. That’s the only way to build great software.”
Each project gets its own Slack channel for conversation about that particular project. We have thoughtbot-only channels for topics like design, design review, sales, cats, parenting, and more. These rooms make the studios feel more like one big community instead of several separated ones.
We have Trello boards for everything from hiring to sales to research. This allows us to track the progress of hiring a candidate or the success of a sales lead in our funnel. In addition to a Slack channel, each client project also gets a Trello board for tracking progress that we’re making on that particular project. We actively encourage our clients to participate in discussions that we have on cards and explain to them how we write new ones and prioritize them.
We use an internal tool called Constable for team messages. Constable posts are broken into tags for interests similar to our Slack, so we spend less time managing emails. We usually announce new hires, new internal projects, updates from offices, and more via Constable.
“What separates designers is how well they know themselves and trust their process.”
How do you hand off designs to the engineering team?
We work so closely with our developers that there really isn’t a handoff. They’re involved with the project from the start by participating in research and in our design sprints. They each bring their own unique knowledge and perspective to the design process.
We use Trello to handle feature tracking and any handoff we do have. We break down each story using the Jobs To Be Done story format. I’ve found that the designers and developers have more empathy for their users with this format. Every story is design-led and is open for any solution to the job. This allows for the team to hopefully work together to design and build the feature.
Design could simply be a sketch for a developer to interpret, or it could be static HTML and CSS in a branch for a developer to take over, or something in-between. How this gets handled depends largely on the team individuals as well as on the problem they’re trying to solve.
“It’s never too early to ask for feedback.”
Tell me about your hiring process.
We believe that a diverse team makes the best products
, so we don’t look for people who come from one specific background or path. We look for designers who can provide new perspectives and teach the team something new.
We ask to see a portfolio as well as some HTML and CSS samples to get an initial sense of their skill level. When those come in from our hiring form, I usually look over them and see if their skills would make them successful at thoughtbot as designer. If I’m on the fence, I’ll usually ask for a second opinion from the designers at the studio they’re applying to.
The next step is a non-technical interview, usually with me. We discuss their experience as a designer, the teams they’ve worked on, what products they’ve worked on, and what they’re passionate about. I’m usually looking to see if they’d be a good fit for thoughtbot. Are they a leader on their current team? Are they someone who can self-manage? Are they someone who has ideas about how to build software more effectively? I’m also looking to see what passion and drive they can bring to the team. Where do their interests lie? Where do they excel, and where do they see places for improvement?
The next step is the technical interview, where the candidate will speak with another designer about their process on a recent project. We’re paying attention to how they approached the project and in retrospect, how they could have done a better job. I really like hearing about failure and how they and their team dealt with it. We also ask questions about HTML and Sass. We want to make sure that their code knowledge is current and that they won’t be in over their heads building products on a client team.
The final step is an office visit. Applicants pair with designers in the morning and typically tackle front-end problems. This includes small bugs or features that show both their problem-solving skills on a small scale, as well as their knowledge of HTML and CSS. In the afternoon we give the designer a challenge. We have a few briefs that we choose from and send the day before so that the candidate has some time to think about the design problem they might be solving. They have the opportunity to ask us questions right after lunch.
We’re seeking candidates to lead us in some design exercises much like we do in a design sprint. The challenge is supposed to mimic a briefer start of our process. At the end of the day, they present their work to designers and developers that are interested in attending. They’re expected to discuss their design and thought process for what solution they arrived at, as well as what their process was for getting there.
The designers watch the presentation and act like a client, asking questions about the solution. We’re watching to see how open the candidate is with feedback, how much they’ve thought through solving the user’s problem, what the smallest solution is to test assumptions we’re making, and where they might have conducted more research to validate those.
Should designers learn to code?
Here, our teams work best with designers who write HTML and CSS and aren’t afraid to jump into a mobile codebase either. We’ve found that it works best for the small teams that we have. This doesn’t necessarily mean that it’ll work for all teams, projects, or designers.
I encourage any designer who’s curious about code, whether that be HTML and CSS, Javascript, Swift, or Rails, to dive in and start building something.
I do think at bare minimum designers need to know what is and isn’t possible on the medium they’re designing for. That might take the form of having some knowledge of HTML and CSS and programming, but it could also mean having a great front-end developer, sitting next to them and constantly questioning them about the medium. That’s not limited to the web—it also applies to any other medium, like print. You might not be the one printing everything, but you need to know how something is going to be printed and the constraints of the medium.
How did you get to where you are now?
Growing up, I was really into drawing and painting. In high school I took a class on Photoshop and Illustrator using one of those colorful iMacs. We used to save everything we made directly to a ZIP drive. I got hooked on doing art and design on the computer.
I went to Endicott College and studied visual communications. My roommate Mike Kivikoski and I both fell in love with designing for the screen. We played around with Flash and built interfaces with HTML and CSS. Most of the design courses were focused on print and branding—they hadn’t yet caught up to the web, so we taught ourselves and showed each other what we built and how.
Out of college, I got a job as a web designer at a Fortune 500 company, but I wasn’t happy there. I spent most of my day-to-day designing HTML deal emails using bright reds, yellows, and all caps. It wasn’t glamorous.
I applied to thoughtbot for a design position twice and got the job the second time. This was back when we only had our Boston studio. I was there for about 3 years before moving to Philly, where I was asked to open a studio there. Because of that, my role went from Designer to Managing Director of the Philly studio. I was the only designer in management at the time, and I felt the need to support the design team.
I’ve always wanted thoughtbot to be known more for our design than our development. I initiated one-on-ones with designers, trying to figure out how to make thoughtbot a great place for them to succeed, for us to push well thought-out applications, and to ensure that the designers at the company felt supported in any endeavor they hoped to pursue. I pushed for more designers in management positions. That work led to my title of Chief Design Officer and gave me the opportunity to promote a designer in each of our studios to the position of Design Director.
Does your team trust each other? How have you built that up?
I think that’s the only way to build great software. Our design teams regularly hold critiques in each studio. We post designs and pull requests for review and feedback in front of the whole company so that someone else looks over everything we do. It ensures that all of our work is the highest quality, and it also proves to be a great place for designers to teach each other and learn. They also open up creative exercises on Fridays to everyone at the company. We’ve done lunchtime drawtime, crocheting, design challenges, and more.
Only hiring people we know will be successful at thoughtbot is key. Knowing that each designer went through our rigorous process and has a similar skillset builds trust from the beginning.
Are there any qualities in your design process that you consider unique?
All of our designers see the project through from business strategy to implementation. There’s less communication overhead and more of an opportunity for us to be seamless from role to role. This means that the designer has a lot of influence over the product that’s being made. They can design and build features that they believe solve the problem based on research that they, themselves, conducted. The loop of getting feedback, designing a solution, and implementing said solution is really short because only one or 2 people complete it. I’ve had days where I’ve conducted interviews in the morning, saw issues in the app, and then pushed fixes for them in the afternoon.
“Only hire people who you know will be successful.”
What do you think is the most powerful part of your design process?
The start of the project, when we conduct research and run a design sprint. It’s really easy to jump right into building the wrong features for clients, wasting our time and their money. Design sprints help you immediately put a lot of emphasis on building something that solves a problem. The research and design sprint are meant to give us confidence early in the project. We go into building products with some validation and are continuing to get that validation throughout the time the client is with us. We do so by talking to users and seeing how they operate the software we build.
Related: Frequently asked questions about design sprints
What are some design trends you’re interested in or currently trying out?
I’m mostly interested in figuring out how design thinking and research can influence our clients’ projects so they leave thoughtbot with a successful application that solves a need. I’m interested in different design research techniques and prototyping techniques to get early validation that our teams are heading in the right direction. Lately, I’ve been digging into Jobs To Be Done to help me figure out where the problem really is and how people are currently solving for it.
What do you think the design industry is going to be like in 5 years?
In 5 years, designers will have a greater effect on business decisions. I think for a long time, engineers and traditional business folks were the ones at the head of a company. I also think design thinking and design leadership can help make a company successful. Starting a company with design at the forefront and looking at all processes as being designed will be important.
In terms of technology, I think we’ll start to have more variety of devices we’re designing for. I picture technology such as watches that need simpler interfaces for complex interactions, or VR devices that might have much more rich and complex displays that we’ll need to create deep and engaging experiences for.
“In 5 years, designers will have a greater effect on business decisions.”
How do you use InVision as part of your design process?
We use InVision for prototyping during our design sprints. Since we have just one day to design and build a prototype, having a tool that allows us to easily push out a clickable prototype to show in front of users is paramount. InVision makes it easy to turn sketches into prototypes we can show potential users.
What’s your best advice for young designers?
Always start with a problem, and then create solutions with your team. Rely on your team’s experience and knowledge. Everyone brings something different to the table.
It’s never too early to ask for feedback. The more eyes I get on a user flow, visual design, or HTML and CSS, the better it’ll be.
Never stop learning, and follow your passion. If you like implementing your designs, learn how to do so. If you love doing research, do more of it. If mobile is grabbing your attention, work on it.
Figure out your process. Everyone’s is different, and what separates designers is how well they know themselves and trust their process.
Oh, and have fun. We get to live in a time where we make magic happen on screens all across the world. It’s an amazing thing. Enjoy the process of making things that people use.
