Bringing Design in House

HOME  /  PHILOSOPHY

TLDR: Design encompasses a collection of diverse skills, and requires preparation and commitment from leadership to bring it in house. Design is 70% strategy and 30% production. Treating it as such ensures efficiency gains, and makes room for more scalable, high-quality, customer-centric products.

tartups looking to build their own in-house design team often do so to gain control over the creative process and have assurance of timely, ongoing delivery. What startups often don't realize is that bringing design in house requires finesse and planning so it has a chance to make a lasting, positive impact on the business and the user's experience without obliterating product release cycles.

One of the biggest concerns product leaders face when hiring their first designers is the risk of slowing down feature releases. After working without this step in the software delivery process, and still feeling "behind" on cranking out new features, the perceived risk of delaying even longer by incorporating design into the process means designers are left out of the process for as long as possible. But the tradeoff of continuing to let engineers design and build the product limits growth and adds to product delivery cycles with more nefarious, long-lasting consequences.

The longer a startup waits to hire designers, the more design debt they incur. The more design debt, the faster they want designers to work. The faster they want designers to work, the poorer quality and culture they build until they run off all their best talent.

There is a better way.

Don't Let Design Slow you Down

One common way that startups unwittingly slow down their software releases is by hiring the wrong kind of designer, or worse, hiring multiple junior designers simultaneously.

The best founding designers don't just represent the voice of the customer and create prettier visuals—they understand how to balance speed without sacrificing scalability as they design. Designing for scalability is how startups can avoid the biggest delays in ongoing feature releases while also creating happier experiences for customers and fewer customer support calls.

What to Look for in a Founding Designer

Founding designers are unique—they are not like other designers. They possess a business-centric mindset and a diverse set of skills to craft user-centered designs:

  • Managing ambiguous requests
  • Managing the personalities that habitually make ambiguous requests
  • Conducting productive user research that provides strategic insights (not just asking for feedback on a design they just made)
  • Demonstrating a solid grasp of both UX and UI design
  • The patience and ability to negotiate with engineers, asking the right questions so they can design with technical limitations in mind, and find ways to make engineering's lift a little lighter

You won't find these kinds of designers coming out of UX bootcamps, or even from senior positions at larger corporations. Many of these skills are learned from being thrown into live projects with high stakes, and in the absence of supportive structures. In other words, look for someone with grit and experience from taking risks themselves—designer entrepreneurs, startup veterans, and in some cases, agency designers. They are used to wearing multiple hats, figuring things out as they go, being quick to act, while being thoughtful of quality.

How Many Designers are Too Many

Bringing multiple designers in house simultaneously is far more likely to slow efficiency until those involved in the production line have a chance to settle in to a new collaborative process. This is especially true if these designers are not familiar with startups, are junior or mid-level, are more gifted in UX but not in UI, and don't have an experienced design leader to advocate for them.

Without an experienced design leader to help establish cross-functional process, guide less experienced designers through an iterative design process, and divvy up tasks, any number of designers could create enough friction in the process to erode product delivery efficiency. Even hiring another junior designer and a very senior designer could be enough to distract the senior designer from getting more done than they would if they weren't mentoring a junior designer while also doing a monumental amount of design work themselves.

The question of how many designers is needed for a startup should be assessed by someone who understands how much design work needs to be done for a given timeline. Vetting the work required, and getting recommendations for the skill sets needed could be asked of a contractor initially just to get the proper job descriptions and roadmap in place.

Generally, I advocate for hiring just one founding designer with previous startup experience who also meets the criteria above. They can help assess the work needed, and can often do the work of 3-4 less experienced designers at least initially. Consider this when negotiating their salary.

Adding Design into the Production Process

Inefficiencies that occur after bringing design in-house aren't due to the design process itself, but are more likely due to misunderstanding or not accounting for what designers need to kick off their work. Unless an experienced design leader is at the helm of this transition, this role is commonly left to non-designers who may not know how to get the results they're looking for when working with creatives.

To deliver high quality work efficiently, designers need to have enough information to make decisions that will support both the user and the business. That, in addition to being given an appropriate amount of time to do the work, and an understanding of how a feature needs to exist now in the context of the product today as well as how it may need to flex in the future, will lead to much more satisfying and scalable results. Having direct access to speak with Engineering about what could happen with any given design approach before continuing down a path will also save loads of painful rework.

How to Request Design Work to Avoid Delays

When requesting design, product leaders should neither see it as commissioning an artistic rendering or ordering a prefab part for a machine. Design exists somewhere in between, using existing elements and flows to create something new yet familiar to users while working within the constraints of the existing product. A successful new feature is designed through hundreds of micro decisions that rely on outside information.

I've been in many a meeting where a design request will be made by one or more executives without any critical details:

  • No timeline
  • No core use case
  • Unclear or contradicting user pain points (to accommodate all edge cases)
  • No mention of technical requirements, potential error states, or limitations within existing features or user flows

This is a recipe for spinning wheels and a long game of hot potato between Engineering and Design. That is, unless the designer knows how to ask the right questions and they have someone reputable there to answer them. A major part of my job as an agency owner, an individual contributor, and a director of other designers in house, has been translating non-requests into tangible, measurable requirements so designers can take immediate action.

Avoiding this messy business of designing without constraints requires hunting down the inevitable limitations that should be guiding design work. This is collected through conversations with other product leaders about current, past or upcoming features, users (of course), and engineers.

  1. The more work that has been done up front by the requestor to define the limitations, the less time designers have to spend researching so they don't come to the wrong conclusions. Designers want to mitigate risk just as much as anyone else in the company. The way to facilitate faster design is to come prepared to answer their questions so they can explore solutions within the context of a well-defined problem to solve. (Some designers will rely too heavily on research before they make a move, but that's a post for another time.)
  2. Design works best within limits. Software design always has limits to work within, but they are often not realized until either the designer or engineer is too far down the path of a single solution.
  3. Work with an experienced designer to define the requirements—or to collaborate with a product manager to do so. Jumping into work before understanding the problem to solve is more costly than not doing the work at all.

The request for work is where most projects begin to derail. Spend time making sure the right work is being pursued, and that all contributors are aligned with their role in making it successful.

Encourage Exploration

Designers will deliver better work when they have freedom to explore different design options. While productive product designers shouldn't be fantasizing about the endless possibilities of what could be, they also can't explore just one option and expect it to be an adequate solution. There is always a need for some amount of experimentation—however minute it may be—to weed out less successful design solutions. Often, the first solution presented will be the weakest. It is rarely the strongest.

Acknowledge the Differences

  1. Rather than wedging designers into existing workflows and tools that are suited to the needs of engineers (JIRA, for example), consider, how much faster, collaborative, and happier designers will be when they have the support they need to do their best work.Designers don't work the same way that engineers do. Their tools are different, their workflows are different, their outputs are different and not measured in the same way as engineering's efforts are measured. While it may not be practical to have completely separate systems for managing the converging workloads of designers and engineers, there may be better tools that can solve for both parties in a more reasonable way. Tools like Figma, Zeplin and Clickup are making moves to bring these two worlds together in a way that acknowledges the differences without playing favorites.
  2. Without experience or exposure to how design works, it's rare that an organization can successfully attract or retain design talent because they will inadvertently place designers in a position that prevents them from delivering meaningful value.For example, instead of being able to meet with customers to explore pain points and present insightful solutions for feedback, designers may be told off-the-cuff anecdotes by those requesting the work as a substitute for more insightful input from the users' mouths. While this can seem like a time-saving measure, it does nothing to help the designer empathize or understand the deeper user need that they have been trained to ferret out and incorporate into their work. Instead, consider sharing recordings of previous sales calls, or allowing the the user to hop on the next customer success phone call on mute.
  3. Design is never just surface-level. Making any changes to a pre-existing UI will almost always have a cascading effect in numerous other areas of a product. When requesting a design update, understand that a designer's role is more than just scooting pixels around a screen, and that a change may extend beyond the one screen in sight. Instead, capitalize on their practical problem-solving skills, strategic systems thinking, and natural empathy for customer needs by sharing the "why" behind the ask and letting them come to the conclusion of how to resolve it.
  4. Designers need an advocate in leadership to ensure they receive enough context and latitude to allow them to deliver value. Designers don't tend to be power-hungry—they are often their own biggest critics. They will generate more powerful work when they are given the opportunity to explore and then articulate informed solutions. They are most satisfied in their jobs when they can see that their work is actively improving the lives of users.

For design to be fully integrated into a tech startup, a few things should be considered:

  1. Design is its own unique discipline. It comes with its own process, its own tools, and its own nuanced modalities and roles. 99% of designers use a Mac rather than a PC. They need licenses for professional design software, like Adobe Cloud, Figma or Sketch. And, for best results, they need to be given room for both quiet, independent study and collaborative white boarding (virtual or otherwise). Depending on the type of work, they may also need specially calibrated retina monitors and additional licenses for third party tools, like Loom, Zeplin, font libraries, Dropbox or a Brand Management Platform. Depending on their role, they will need access to stakeholders, customers, business metrics and future business development ideas so they can consider how the product needs to evolve to meet demands. Though this may seem like a lot, these aren’t the wants of pampered artists—they are the needs of effective creative workhorses.
  2. Designers have widely varied skill sets, some of which don’t even include visual design. UX designers, for example, are explicitly trained to consider the pathways by which a user can move from one place to another to complete a task. As designers of experiences, not visuals, they may not have the design acumen to go beyond drawing boxes and arrows diagrams. Yet, it’s not uncommon for designers of all types to be expected to write copy, design icons, piece together interactive prototypes, animate page transitions, or conduct user research interviews. The range of skills embodied in a generalist designer is commonly needed in a startup, especially in the very early days. But without proper awareness of what to look for in terms of skills and experience, it will be exceedingly difficult to find and attract such versatile, high caliber designers. These varying skills (and more) are not going to be performed to the same level of quality or accuracy by every designer. It’s critical to consider which abilities are most important to accomplish particular design tasks. Hint: Visual design should be lower down on the list of priorities.
  3. Design is 70% research, strategy and systems planning, and 30% execution. If design isn’t given time to do the heavy lifting up front, the risk of needing to redesign escalates immediately and as the product scales. Just because something looks polished, it doesn’t mean it will perform as seamlessly when it’s in the hands of users.
  4. Design needs a heads up. There’s typically a period of triaging that takes place before design has the opportunity to tackle projects with less urgency. Problems start when designers are never given relief from this way of working. Just like engineering teams can acquire tech debt over time, designers are hit with loads of base-level systems work that only grows with each new project. This is one reason why it’s important to have a seasoned designer guide the workload and develop a strategy for delivering hair-on-fire requests and long-term strategic feature development effectively. Design is most useful in a strategic capacity, which means they need a longer runway to research, explore solutions, test solutions and package up the deliverables for implementation. If leadership doesn’t allow room in the schedule for these activities, it’s not just the product or project that will suffer, but the team’s morale will too. No designer wants to stay in a role where they are asked to do menial tasks in an emergency setting. It’s unpleasant and unfulfilling for any serious creative, and they won’t stay for long.
  5. Design led by non-designers is very risky. Design is one of those things that can appear to be straightforward and approachable. Some tasks may not seem that complex to pull off initially. In fact, many startups ask designers to simply repurpose layouts, taglines, or onboarding flows they’ve seen other companies do. Not only is that illegal in some cases, it also shows a lack of understanding for the value design could bring to the company. If a non-designer is leading the charge on projects, the focus on problem-solving tends to shift to arriving at a solution as quickly as possible. This shortcut shortchanges the company. Instead, by following the full extent of the design process, beginning with research, and iterating towards a solution, the real root problems that need to be solved can be identified and addressed more appropriately and permanently. This approach not only saves the company from producing poor quality work, it also ensures that the users' needs remain in focus throughout the product development lifecycle.

Prepping for the Transition

Transitioning from what is typically an engineering- or marketing-led implementation process to one that incorporates design can cause a series of disruptions if not orchestrated well. So, before drafting any job postings, first understand your organization’s reasoning and expectations for bringing design in house.

  1. To help outline expectations and explore any necessary reorganization of team structures, consider hiring a design expert to consult.
  2. Conduct an audit of the existing product and roadmap. Again, this is where an outside consultant with design expertise can be particularly helpful. Examining the extent of the workload, skill sets and responsibilities required to meet expectations will ensure right mix of designers are brought in to the company.
  3. Consider how the existing organizational structure may need to flex to make room for designers. To do their jobs well, designers need accommodations of time and the permission to follow best practices for design. The most common blockers to this occur because design is squeezed into an existing workflow without being consulted on how they can best offer their services.
  4. Finally, clarify how processes will evolve to include the necessary time, tools and approvals to ensure a cohesive, streamlined experience for all. Each of these factors play key roles in your success, and in minimizing disruptions.

Every team is different. But as long as leadership starts with clear expectations, makes room for designers to operate, and commits to including design in the process, the results should speak for themselves. ⚑