Re-thinking design with Austin Knight of HubSpot

Austin Knight is a writer, speaker, design mentor, and co-host of the UX and Growth Podcast. He’s also Senior UX Designer at HubSpot, where he and his team oversee HubSpot.com

We talked to Austin about the future of design, remote work, and why designers shouldn’t defend their work.

How have you seen the industry change since your first job as a designer, and where do you think things are headed?

For a while now, the industry has been changing at a rapid and accelerating rate. The very concept of UX is new to many companies, while at the same time, more advanced designers are already thinking far beyond that—and they’re correct in doing so.

It’s important for designers to keep disrupting themselves and learning new things. In the past month or so, I’ve jumped onto a machine learning project at HubSpot and started teaching myself how to design for 3D / VR in my free time. It’s a modest commitment, but one that has opened my mind up to an entirely new world of possibilities, even within the world of software and web design.

It’s not just a matter of downloading the new AR app, getting the new IoT device, or buying a VR headset. Designers need to cultivate a working understanding for how to build with these technologies. Because ultimately, it’s impossible to truly predict what changes will materialize. Artificial intelligence, deep learning, augmented reality, and countless other technologies will have unimaginable impacts on our work.

The key is to be open-minded and adaptable enough to confidently embrace the technology when it arrives. Change is inevitable. The only thing you control is how you react to it.

You’re currently working remotely in Rio de Janeiro. What led you to make that decision, and do you have any tips for working remotely?

It turns out that travel and creativity are actually closely related to each other. Around a year ago, I started travelling a lot for speaking engagements and I noticed that it was changing the way I approached design. I was encountering odd problems and radical solutions that I had never even considered before, meeting people who viewed design in a completely different way than I did (or, to my surprise in some cases, exactly the same way that I did), and developing empathy for users that I previously would have never identified with. It was transformational, both for me as an individual and for the work that I was producing.

But I noticed another important thing: those transformational experiences weren’t being afforded to me through short trips or stays at walled-off resorts. It was when I stayed in a place for an extended period of time and I really got to know the local design community that I learned the most. So, when I had the opportunity to move to Brazil and work remote, I took it without hesitation.

Remote work can bring a lot of challenges with it as well, especially when it comes to team communication and collaboration. I’ve noticed that you need to get a few things right before it really works:

• Team attitude and culture. Your team has to be open to the idea of remote work and they have to be ready to make the effort to collaborate across oceans. If your company likes to play games where everyone competes to see who stays at the office the latest, you’re going to have a bad time. Success has to be measured by actual results generated, not time spent or any other kind of political bullshit.
• Tools and space. You’re going to need a good machine, monitor, internet connection, and place to work. You have to be diligent about lining all of that up before you go anywhere. I wasn’t thrilled about dragging a Thunderbolt Monitor to Brazil, but I’m glad I did. And whenever I go abroad, I make sure that I select a good co-working space that can provide what I need to do my job. Slack, Zoom, and InVision also do wonders for live collaboration.
• Personal philosophy. Highly autonomous and motivated self-learners seem to do the best with remote work. Nobody is going to be there to tell you what to do or hold your hand while you struggle to learn 3D. And they’re also not going to prevent you from watching Narcos on a Tuesday instead of attending that company meeting. You need to be responsible enough to teach yourself how to do things and actually get work done, or you’re not going to produce results.

What’s the difference between art and design?

Design and art fundamentally diverge in 3 core ways: the purposes that they serve, the data through which they are informed, and the role that creativity plays in each.

• Purposes: Art is about personal expression, provocation, exploration, and appreciation. The best art is a deep reflection of its creator. Design is about use, alleviation, iteration, and function. The best design is a deep reflection of its user. Through this, we find that art is about the artist, but design is about the user.
• Data: Both artists and designers use their own experiences, opinions, intuitions, and thoughts to guide their work. But designers also heavily incorporate external sources of data, like quantitative and qualitative analyses, usability standards, and business goals. As a result, much less is being left to chance or opinion in design. What we find is that art is and probably always will be subjective, but design is now more objective.
• Creativity: It is perfectly acceptable for the artist to be creative simply for the sake of being creative. In design, however, creativity is used as more of a vehicle to better solve a problem or serve the design’s purpose. While art expresses creativity, design leverages creativity.

This is not to say that design is more important to society than art. I would argue that they hold equal value. But when we start to think of them as being the same thing, we’re likely to think that the genius in design comes from the designers themselves—their intuition, style, taste, and personal opinion. As we deconstruct the design process, however, we find that the genius is not in the designer’s subjective thoughts, but rather in how they interpret and channel their users’ thoughts, opinions, and motivations. This is precisely why it’s so dangerous to confuse the two.

So my suggestion here is not so much that design is not art, but rather that design is not about the designer. It is through this understanding that we can come to a critical conclusion: more than one’s ability to follow a UX process, create a beautiful UI in Sketch, or write a killer Medium post; more than any hard skills, humility is the most important quality that a designer can possess.

I’ve been traveling around the world and speaking about this topic, and I recently published several in-depth essays on why design is not art and why I believe that good design is humble. It’s amazing how this small distinction can completely change the ways in which designers think and work. Any designer, no matter how senior or junior, could benefit from this kind of deep introspection.

How is your team set up?

My team is pretty unique in that we’re distributed around the world and we’re very multi-disciplinary. Most companies will place their website under the control of a brand team, comprised almost exclusively of brand designers. We tend to believe that our website is an extension of our product, and as such, we’ve structured our team like you would a product team. I’m the sole UX designer, supported by 2 of the most talented visual designers I’ve ever worked with, one of which is based out of Dublin and the other of which is based out of Cambridge.

We’re accompanied by a copywriter, 3 developers, a data analyst, an SEO, a CRO, and a project manager.

I also occasionally take on UX interns and design co-ops, with an aim to mentor them in UX and augment our team along the way. Together, we run a site that receives over 10 million visitors and 60,000 leads per month.

Now, this may not look like a typical design team, but I would actually argue that the common design team of today is bloated and ill-focused. Design isn’t just about “design,” in the classic sense. And design teams shouldn’t just be comprised of designers. Empathy, mutual respect, cross-functional trust, and deeper insights come out of multi-disciplinary teams. With this structure, I like to say that we take a data-informed, human-centered approach to design, where conversion and performance are just as important as usability and aesthetics.

Our site isn’t just a branding asset—it’s a revenue driver. When you think of it that way, the structure that we’ve chosen starts to make a lot of sense. Rather than stack the team with a bunch of designers that come from the same background, work in the same place, and think the same way, we’ve deliberately created a team that simultaneously challenges and complements each other’s work. We’re focused on building a world-class site that produces tangible results for both our users and our business.

With that said, we’ve seen the team change a lot. When I joined the company 2 years ago, we were around 400 employees and we had a single product. Now we’re well over 1,500 employees, we’re fully multi-product, and we’re expanding globally with offices in Dublin, Sydney, Singapore, and Tokyo. Our team has to reflect that growth, and it’s important for designers and leaders alike to be open to it. Rapid growth and the resulting uncomfortable change has been the catalyst for some of our greatest ideas and innovations. Get comfortable with being uncomfortable—it will challenge you to think differently.

What’s the design culture like at HubSpot? Why do you think having a design culture is important?

We’re very deliberate and open about our culture at HubSpot, and it’s part of what’s empowered us to become such a design-centric company. We lead with open-mindedness, collaboration, and high individual autonomy. We’re radically transparent, even as a public company. Bureaucracy and ego are the enemy; we believe in fast and humble innovation. A very results-oriented and metrics-driven group, we care more about what people produce than where they are, how long they work, or how much vacation they take (we have unlimited vacation). Most HubSpotters (myself included) will tell you that the greatest benefit of working at HubSpot isn’t the cool office and fun perks, but the people. I’ve never worked with such intelligent, motivated, and thoughtful people in my life.

But perhaps most importantly, we’re built on design principles. 10 years ago, our co-founders recognized that the ways in which people were buying and selling products was fundamentally changing, and so they pioneered a concept called inbound marketing. This innovation led to the birth of the company and the software that we have today. Inbound marketing and UX work extremely well together because they’re built on the same principles of delivering value to users, rather than disrupting them. That makes for a very healthy design environment, where design is valued from the top down.

How does your team collaborate?

Simplicity and consolidation are key for good remote collaboration. We use Slack for ongoing communication, Zoom for telepresence meetings, JIRA for project management, Sketch for design work, and InVision for collaboration and critique. I don’t believe that any one tool can transform a team from a standpoint of collaboration. It’s not the tools that matter, but how you use them. So most of our focus is placed on ensuring that we schedule check-ins at the right time, communicate with the right people, and stay aligned around a common goal.

Do you have a formal review process?

If you look at the UX process that I outlined, you’ll notice that there’s a real pattern of constant feedback, both from inside and outside the organization. So I wouldn’t say that we have a formal review process, as much as I’d say that review and feedback is baked into every aspect of the process. It’s ongoing. Granted, whenever we do reach a major iteration or a point where we need approvals, we’ll get the team together for a more formal review. But even as a fairly large company, we’ll keep these meetings lean and short, appointing small and highly autonomous teams to take on the big projects and make sure they get live.

Related: How to give good feedback

There’s a lot that goes into an effective design review and it can often require a delicate balance between deliberation and action. But regardless of how the pendulum swings, I recommend that designers don’t defend their work during reviews. It’s one of the biggest hidden blockers I’ve noticed, and one of the main reasons why I think teams are always looking for new design review processes. They feel that their reviews are unproductive and stressful, and so they assume a new process would help. I would suggest that it’s not the process, but the mindset of the people involved that matters. So when faced with criticism, rather than get defensive and feel like we need to stand up for our work, we should get inquisitive and feel like we’re encountering an opportunity to improve our work. Don’t get defensive. Get curious.

In order to do this effectively, the designer really needs to be empowered to make the final call on design decisions. I know that can be a tough shift to make, but if you think about the designer’s role, they’re usually best qualified to do this. They sit at the epicenter of all of the feedback and data that goes into the design. They’re the ones collecting information from countless stakeholders, users, and quantitative data sources. This positions them best to determine how feedback and data should be applied.

How do you hand off designs to the engineering team?

I wouldn’t say that we ever do. Our developers are involved in the project from the initial kickoff and their involvement doesn’t really slow from there. They advise on the design, they surface opportunities to introduce new technologies, and they work very closely with us to develop and QA test the final product. They’re comfortable with critiquing design decisions in the same way that I’m comfortable with using Chrome Dev Tools to illustrate ideas and adjustments.

In general, we’re always looking for places to remove or minimize handoffs, especially within the UX process. During previous roles and projects, I noticed that an overwhelming majority of our miscommunications, accountability issues, and delays occurred at a hand-off of some kind. They seem to be the genesis point for many breakdowns and common issues that can simply be eliminated with a more collaborative, autonomous, and fluid team setup.

Can you run us through your design process on new features/products from idea to launch?

When I joined the company, we didn’t have a UX process for my team. So I started by working with the designers to understand their existing process and find areas where we could build UX into it. I think it’s a terrible idea to come into a company fresh and immediately start trying to change things. You’re better off working with the team, listening to them, and collaborating on changes together.

Ultimately, I ended up drafting a new variation of the Lean UX process, which I’ve detailed here. I then put it through several projects, made a few tweaks, and came out with something that we were all happy with.

The process is designed to be inherently fast, iterative, flexible, objective, and results driven. It is broken down into 3 core phases:

• Think: Focused on strategy, research, and analysis. This is where you’ll create historical data analyses, heuristic reviews, user interviews, mood boards, personas and scenarios, user journeys, and more. You’re setting the context for the design that is to come.
• Make: Focused on design and implementation. This is where you’ll create taxonomies, sketches, wireframes, mockups, prototypes, and production code. You’re developing the structure for the design, iterating on it, and ultimately pushing it live.
• Check: Focused on measuring and iteration; the most important step, but often the most overlooked. This is where you’ll go back and look at the design’s performance in your analytics, heatmaps and scrollmaps, user tests, and more. You’ll pull key learnings, plan the next iteration, and shoot back up to the Think phase (oh, and you’ll fix bugs too).

This whole process is cyclical and it acknowledges that websites are not static brochures; they’re dynamic assets that should be constantly adapting and improving. The greatest benefit from here is that the focus is placed on shipping the design, learning from it and allowing your users to determine the direction (rather than allowing stakeholders to spin their wheels in pursuit of perfection or personal preferences). It aims to yield real results and real learnings, not subjective opinions.

Have you come across any really amazing user experiences lately?

DuoLingo has one of the best onboarding experiences I’ve seen, and I talk about it all the time. It’s an excellent example of “value first” design. Open the app for the first time, choose a language, and start learning it. Then, after completing your first lesson, it will ask you if you want to save your progress. That’s when you create an account.

The app delivers value to the user before asking for anything in return. And even in asking for information, it’s positioning it as a benefit to the user, rather than an exchange that must be made in order to gain access to the app. There’s a lot to be learned from that, even beyond onboarding.

What types of metrics do you watch closely while making design changes?

We generally ignore vanity metrics like Bounce Rate and Time on Site, and pay much closer attention to user behaviors. Especially behaviors that we know drive tangible business results. In the context of Google Analytics, this would encompass reports like the Goal Flow and User Behavior Flow. We couple this with user session recordings from Hotjar, heatmaps and scrollmaps from CrazyEgg, task ease and completion rates from UsabilityHub and in-person user testing, and HubSpot’s amazing user-specific analytics and experimentation capabilities.

Design can be a very difficult thing to measure, but we’ve just about gotten it down to a science. In a conversation that I had with Dr. David Darmanin (CEO of Hotjar), he suggested that user feedback should drive feature creation and then conversion should verify whether or not the direction was correct. I think there’s some seriously underrated value in that mindset. It lends itself to the idea that while data can make a good design great, it can’t make a bad design good. Hence the focus on a data-informed and human-centered design.

So we start with a good concept that resulted from user feedback, stakeholder requests, historical data, and some designer input. We then launch the design and maniacally track metrics like conversion, retention, and revenue over long periods of time and throughout our entire funnel. We’re not just looking to see if the button got clicked more; we’re interested in whether it resulted in more submissions, sales, and happy customers. Even if it’s across multiple sessions. That information is then used to inform the decisions that we make and experiments that we run in our next iteration. We strive to objectively justify every design decision and point each iteration closer toward our goals and our users goals.

What do you think is the most powerful part of your design process?

Fluidity. It’s easy to fall into the trap of thinking that a design process should be implemented rigorously, and only then will it account for every issue and circumstance. But processes aren’t meant to be all-encompassing nor rigorous. They’re just frameworks that have been created based on previous experiences, intended to serve as general guides. Our process really accounts for that. Phases, deliverables, and actions are completely driven by the unique needs of the project, meaning that sometimes we’ll skip straight from brainstorming to wireframes, and other times we’ll do the full process with sketches, paper prototypes, you name it. The key is to be flexible and have a true understanding for how, when, and why a step needs to be taken.

How do you use InVision?

InVision is the constant in our design process, meaning that we use it at virtually every phase (and this is intentional). We use it in several important ways:

• Sharing and annotating designs: Even in the early stages, we’ll upload wireframes and mockups to InVision for sharing. Important elements are annotated so that stakeholders can get an idea for what they’ll look like or how they’ll work, even when the design is still in a low fidelity stage. Most importantly, as each design is updated, it will be replaced in InVision. We can then use version history to go back and refer to older iterations of the design if necessary.
• Collaboration and feedback: Stakeholders can comment on the design and designers can use this as a log for action items (resolving them when they’re complete). Using LiveShare, we can collaborate remotely and in real time.
• Presenting work to stakeholders: Designs can be shown on the actual device. Using tour points, we can build self-guided tours through the design, so that designers don’t have to present and re-present their work.

“InVision is the constant in our design process.”


• Demonstrating functionality: InVision has some pretty robust prototyping capabilities, so we’re able to build out functionalities and demonstrate how the design would actually work.
• Testing with users: Because we can create a design that looks and functions like a final product, we can test our designs with real users before producing any code. We do a lot of that.
• Documenting specs for our engineers: Using InVision’s new Inspect tool and annotation capabilities, we don’t have to rely quite as much on redlines and spec docs to share guidance with our developers. This is all automated through the Sketch file import, which saves a ton of time. No more guessing over type size, spacing, element size, etc. It’s all there.

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

We have very aggressive and tangible goals that we’re focused on hitting, so success to me is hitting those goals while serving our stakeholders and delighting our users. It’s no easy task, but it feels great when you can find solutions that truly account for both the user and the business. But, of course, this doesn’t come without its fair share of failures. We’ve developed a culture that embraces failure and seeks to learn from it. I discuss our approach to success and failure in an episode of the UX and Growth podcast, but the gist is that an experiment isn’t truly a failure until you fail to learn from it. So we’re focused on hitting those goals and extracting learnings that can propel our next round of work.

Do you have any advice for young designers?

I’m going to offer 2 pieces of advice, starting with something tangible and then moving into something more philosophical. Both are equally important in design.

Build something, then put it in your portfolio. Many designers ask me how they can get started in UX, and I tell them that if they’re asking that question, they’re already doing it wrong. No mentor, professor, or thought leader is going to be able to tell you any magic words that will land you your first job. That’s all up to you.

UX isn’t something that can be taught in a classroom; it has to be practiced. So start practicing it. Build something real and put it in a portfolio (I always suggest coding your own). Work out the kinks and gain an appreciation for not only what deliverables you need to create, but why you need to create them and how they work together with the deliverables that precede or follow them.

I began by creating a real 501(c)(3) non-profit organization. I built the website, I made the videos, I gave real speeches, I fundraised, you name it. This taught me how to design for a real organization, with real goals and limitations. While it wasn’t my initial intention (I was genuinely interested in the cause that I took on), this ended up turning into an amazing case study that landed me my first job.

Others will create hypothetical products, build basic apps, or even volunteer their services to existing non-profit organizations or local businesses. The key is to take on a project with real goals and limitations, show how your design process works within that context, produce real results, and then recount what you learned from it. Show how you think and what you can actually do. You’ll probably have to work for free the first couple times. That’s alright—your goal here is to get a great project that teaches you a few things and ultimately showcases your abilities. So focus more on the experience that you’ll get out of it, rather than the monetary gain. Money will come later, in multiples of whatever you’d be offered today. Many designers fail to ever understand this progression.

Don’t underestimate your potential, nor dwell on your disadvantages. I grew up in rural Kentucky, where the allure of Silicon Valley couldn’t have been further away. In high school, I was ashamed that I was more interested in building a website than trying out for a sport. I had no idea that my abilities would not only be highly valued, but would empower me to self-actualize at a young age. Had I not looked out beyond my small community and perceived disadvantages, and realized that there was something else out there, I may have never chased it. I may have never even known what life I could have had.