Designer’s Field Guide

Building The High Throughput Design Studio

How to make design a growth enabler for your company

A bit more than two years ago I was the first design hire at Jut, a streaming analytics start up. Over that two year period, in addition to doing UX design and strategy, I built a small but very effective design studio consisting of myself, 3 full time designers and two contractors. This was my chance to put into practice a number of my ideas about “operationalizing” design: making the design function into a predictable, efficient and high throughput part of a company’s engineering and marketing machinery. The general consensus at Jut was that this experiment was a success, so I am sharing here the best practices I learned from the experience.

I intend this post to be read more as a reference than as a linear narrative. I’ve divided my thoughts on best practices into the sections listed below, with each section as a stand alone micro-essay of the pithiest, most useful bits regarding how that topic relates to managing the high output design studio.

• The Studio Strategy
• Defining Studio Value
• Physical Set Up
• Team Meetings
• Roles
• Managing Vendors & Contractors
• Resourcing
• Design Standards
• Scheduling Expectations
• Integrating with Development
• Integrating with Marketing
• Further Refinements

The Studio Strategy

My vision of the high output design studio is a function that is fully capable of delivering all the design services required by engineering and marketing. In other words, I see my studio as producing a product — design services — that fully meets the needs of my customers: engineers and marketers.

But what about the company’s customers? The end users who experience the product and the marketing around it are also studio customers. In fact, they are the studio’s most important customers. If they are not happy then the company’s business strategy is at risk. However, the design studio doesn’t service end users directly, but as a collaborator on the implementations produced by engineering and marketing. This is the central paradox faced by the design function: how to service the business’s most important customers indirectly by providing great direct service to the company’s internal stakeholders.

I think the solution to this paradox is the integrated design studio for these reasons:

• A seamless customer acquisition funnel is the highest priority. A paramount business goal in any context is a customer acquisition experience that feels like a seamless and charming journey for the prospect as she moves through the funnel from awareness to engagement through sign up, on-boarding and into the product. The best way to ensure that this experience is smooth and integrated is by having a single collaborative studio produce all features of the journey.
• Design synthesizes strategies. Inserting the design studio in the middle of the production workflows for both marketing and engineering at the same time creates a team in a great position to notice, report and work to mitigate any divergence in strategy or expectations between those two extremely capital intensive engines of growth.
• An integrated design function communicates better. The traditional separation between marketing design and product design is not efficient because communication between teams is always less efficient than within teams. When marketing design and product design are managed as separate functions with different executives, there is a higher cost in making sure that marketing messaging and product realities are aligned from the customers perspective.
• An integrated design function uses resources more efficiently. A studio with a broad portfolio of work can justify a staff with a more varied skill set. For example, it is a great thing for the product user experience for a design studio to have easy access to an excellent visual designer, but it is difficult to find impact work for this resource all the time with only product projects. However, when that resource can move between product and marketing projects, he can be on high value projects all the time, and even when mostly focussed on marketing he can always find a few ad hoc hours to add a bit of visual magic to a product UI that makes a huge difference in the end user experience but is difficult to justify bringing in a contractor to do.
• It is fun. Designers love to work on projects that go end to end, from big picture to small detail and back. A design studio with a mandate to integrate the customer funnel from marketing to product has those kinds of projects in spades. This makes the studio a really fun and exciting place to work which in turn makes it much easier to attract and retain great design talent. And in the end, top notch design talent is 100x more important to the high output design studio than any other thing I write about in this entire essay.

Defining Studio Value

Sometimes a better way to justify the integrated studio is to talk about specific values rather than strategy. In other words, exactly what returns will those studio budget dollars buy? Here is my list of the distinct types of value the integrated, high output design studio delivers.

Design Standards

• Visual and interactive style guides
• Example layouts
• Principles and heuristics for UI quality control

Product Strategy & Design

• Visualizations/wireframes of the future
• Competitive analyses
• Research findings of unmet customer needs
• User scenarios
• Interaction models
• Workflows rendered as flows, wireframes and hi-res comps
• Interactive prototypes

Brand Strategy & Expression

• Expression of brand message through graphic design, illustration and animation
• Web page design
• Style and template development for CMS

Technical Strategy

• UX requirements for underlying technical architecture
• A high level view that helps engineering find and remove inefficiencies/redundancies in system
• Prioritization of functional use cases

User Research

• Personas
• Ethnographic research
• Usability testing
• Recommendations for product change

Production Support

• Design & implementation of front end design system
• Pull Request reviews & firefighting
• Process improvements

Company Culture

• Lean & iterative methodologies
• User-centric approach
• Focus on consistent narratives
• Creative problem solving techniques

The Physical Set Up

One of the important functions of the integrated high throughput design studio is to help everyone else in the company stay aligned on strategy and tactics. Despite the fact that so much communication is now electronic, I find that setting up the studio to encourage physical conversation is a huge help in executing on this function. Here are a few specific physical ideas that work well.

• Locate your studio in the physical center of your company’s office space. Welcome & encourage folks from other teams to walk through your space, look at your monitors, interrupt and ask questions.
• Seat your staff next to or across an aisle from each other. Each designer needs to be able to see the monitors of other designers and give and solicit feedback without (always) needing to move from his seat.
• Invest in several 4'x8'x1/2" sheets of foam core that can serve as portable pin up walls for project artifacts. For active projects, and particularly ones that are new or where the concept is still in flux, cart these to every project meeting. In between meetings, place them around the office and encourage your staff to jump up and explain them to anyone who shows any curiosity.
• Ensure there are always Post-its and Sharpies in every conference room. This supports the development of a company culture of active, visual, workshop-like meetings. Having these simple tools already in place in the meeting areas saves time and helps makes using them feel normal.

Team Meetings

Communicating externally — sharing ideas and concepts with other teams, individuals and customers — is the raison d’etre for your design studio. It turns out that being good at communicating externally happens naturally if your studio is good at communicating internally. The reason is that a studio with a rich internal conversation and collaboration develops a kind of ‘one mind’ about design philosophy and vision. This, in turn, results in your staff naturally and organically communicating externally in a way that is consistent and aligned. Building and maintaining this ‘one mind’ follows from a good physical layout augmented with a few types of recurring meetings.

Design Planning Meeting

Purpose: (1) give each designer an opportunity to inform the rest of the studio about his priorities for the sprint, and highlight any specific risks or help he needs (2) give the design manager an overview of the studio workload for the sprint to understand if the studio commitment for the sprint is reasonable.

Frequency: This hour long meeting recurs every sprint, the day after the scheduled engineering sprint planning day.

Mechanics: Prior to the meeting, each designer must enter all of the work he has committed to for this sprint for each of the scrum teams he supports as stories into JIRA (or whatever task manager your team uses). During the meeting the Design Manager projects on a screen a board showing the stories for each designer in turn and that designer discusses each of his stories, the project it is relevant to, how difficult it will be, what risks it contains, etc.

Team Lunch

Purpose: To be a regular opportunity for the studio to break bread together and get to know each other as people.

Frequency: This meeting recurs every Thursday. That is the best day. The hard part of the week is over so a midday social event Thursday gives a warm kick off to the wrap up part.

Mechanics: Each week the responsibility for leading the team to a lunch spot rotates to a different team member. The expectation is going dutch, unless the Design Manager happens to have budget to pay for everyone. The ‘rule’ is no discussion of work issues. Sometimes it is nice to invite folks from another team to join the lunch to build relationships with them.

Design Critiques

Purpose: To provide designers who need for feedback access the entire studio design mind without having to worry about scheduling.

Frequency: This hour long meeting is pre-scheduled and blocked out on everyone’s calendar for twice a week.

Mechanics: On the day a critique is scheduled, prior to the meeting time, the Design Manager sends out a message asking if anyone has anything to share for the critique. If no one does, the meeting is cancelled. If a meeting is on, the expectation is that everyone in the studio will join and participate. No more than 2 critiques can be accomplished in a single meeting. Designers are encouraged to invite collaborators from other teams to relevant critiques. In person critiques are always best but if even one attendee must be remote, seriously consider having all attendees join remotely (if even from their adjacent desks) to avoid imbalanced meeting dynamics.

Studio Chat Room

Purpose: To provide a private, team chat for asking questions, making jokes and blowing off steam where everyone can count on messages going out to people with a tightly shared understanding for all references, nuances and slang.

Frequency: Ongoing.

Mechanics: Using whatever chat tool your company is using (aka Slack) create a private studio channel. As much as possible message here, and not with email.

Roles

These are the role names I use to group the kinds of designers required by the high throughput design studio. In general, designers have skills that span these groupings, but any given designer is most proficient at one or possibly two of roles over the others.

Director
A team leader who has credibility to direct and inspire creatives, can manage budget and resources, and brings a user centered perspective to company strategy

Product Designer
A problem solver who can design interactive workflows that integrate user needs, business goals, technical constraints and schedule requirements.

Visual Designer
A commercial artist who focuses on the clarity, details and aesthetics of the presentation layer.

Brand Designer
A story teller who uses the tools of graphic & motion design to communicate the marketing message.

Data Visualization Designer
A technical illustrator who uses graphical presentations of data to connect the quantitative to the qualitative

Design Technologist
A programmer with a passion for using code to realize design intent and standardize patterns.

User Researcher
An ethnographer who gathers data about user experiences and organizes it into quality feedback or ideas for new functionality.

Producer
A tactician who delivers high design throughput by helping designers produce the right deliverables at the right time to integrate with planning and development processes.

Managing Vendors & Contractors

Finding and using outside help efficiently is critical to running a high throughput design studio. In the early days, or whenever you need to ramp up capacity, you will find it far easier to use temporary resources than hire new full time people for two reasons. First, it always easier to get budget for temporary expenses than new permanent headcount. Second, it’s faster to find and qualify a temporary resource than a permanent one. Of course, external resources have downsides, with the most salient — from the perspective of the high throughput studio — being communication inefficiency. Here are a few things to keep in mind regarding this challenge.

• Own the invoice, but not necessarily the vision. Managing priorities is the key to running a high throughput design studio and in order to manage the priorities for a design resource you must be the one approving the invoice coming from that resource. However, there is a critical nuance here: you do not need to own creative control over the resource, you need to be the one who tells the resource who does have that control! When your stakeholders trust that you can de-couple these things, they will believe that your studio supplies them with on-demand creative power.
• There is an important difference between 50% and 3/5 time. Except in the case of a true expert working independently and exclusively in her area of highest expertise, I’ve found that there is an important difference in efficiency between a contractor who is on a project 2 days/week and 1 day onsite as compared to one who is 3 days/week on a project, at least 2 days onsite. Partly this is because a 3/5 time resource develops more efficient communication channels to the rest of the design team and other collaborators. However I also think there is some kind of magic ‘engagement’ threshold that produces a qualitative jump in creativity and innovation once a person begins spending the majority of her week on one project.

Resourcing

In order to be a high output design studio, you must be efficient with your resources. That means understanding exactly what you’ve got and how to move it around to meet stakeholder priorities. Because studio success is all about meeting stakeholder expectations!

At the project level, resourcing is personal. The stakeholders on a given project don’t really distinguish the design output from the designer delivering it.

However, when you want to do any kind of design planning such as being able to estimate costs for a given UX strategy or submitting a budget for headcount you need to think about resources in terms of people units, not real people. Here is how I do that.

• Divide roles up among people. This is a simple idea that I find hard to state clearly. What I mean is that your studio does need all the roles described in the Design Roles section above but any given designer executes on more than one role within a given sprint. Having staff who can switch tasks across a range of roles is, in fact, critical to being a high output studio. The way I visualize studio capabilities is by imagining the time my staff spends doing the activities of various roles in terms of percentage of person, like this:

• Estimate output capabilities in terms of abstract design persons. I use the persons count to set accurate expectations with my partners regarding scheduling design work. For example, in the table above, out of a staff ~5 persons, I have 0.20 visual designer capability (embodied entirely by Harry). Effectively, this means I have one designer focusing exclusively on product visual design issues for one day per week. From experience I know that at this resourcing level I can maintain, perhaps slightly improve the quality of the design system from sprint to sprint but certainly couldn’t absorb a user interface redesign project without adding or moving resources. However, I also see that I’ve got 1.70 or nearly 2 technologists which is probably more than I need for strict design system maintenance so if a stakeholder needs us to produce more product visual design output for a sprint or two I can ask Harry to spend less time doing technology stuff and more time doing visual design stuff without incurring much long term standards debt. If I had to move some of Bria’s time to visual design too, I probably could too, depending on the state of the project’s she is assigned to. (Of course, not all roles are switchable — for example, Bria is great at user research, but no one else on staff is at her level, so if I have to ramp that one up, I have a problem.)
• Resource roles to align with strategy. When asking for more headcount I find I can get funding for the capabilities I believe the studio needs as long as I can show that I am also building the capabilities that the executives want. For example, imagine I find myself in a context where the budget decision makers are sold on the value of visual design, but are less certain about the value of user research (of course, that kind of thing never happens!). Once I get headcount to hire a visual designer, I’ll prefer to find one who has a secondary interest in user research if possible.
• Evaluate overall staffing level in terms of departmental ratios. Another way to discuss appropriate studio headcount is in terms of a ratio between your department and other departments. Constructing a table like the one below is a great way to understand the functional priorities of a company.

• Pay careful attention to the ratio between product/visual design resources and engineering. I break out a metric based on these two roles because they are most directly impacted by engineering resources. In my experience, a ratio of 1/6 is fine and produces a level of stress on the studio that designers can sustain without burnout. A 1/8 ratio becomes a grind, however, impacts morale and will eventually lead to attrition (note, I include front end and back end developers in a single overall ratio because most back end projects have some front end impact).
• Maintain near parity between the studio and the quality function. The QA function evaluates the actual output produced by engineering and marketing. If the morale of the QA team is good that indicates the department is sized adequately to handle the load. Because demand on the design studio for services is driven by the same rate of production output the size of the QA department is a good reference for the design studio.

Design Standards

Design standards is about a culture of doing the simplest effective thing. Effective means that delivering a useful solution to the problem is a must-have. Simplest means you want to do it in the most efficient way possible. Most of the time this means using pieces you have already created. Sometimes it means making new pieces.

Rationally, this is a great approach because it increases throughput, that is, it increases design efficiency and it increases production efficiency. But my favorite reason is the emotional one: standards make people happier. Designers love patterns but are much happier when they don’t have to repeatedly redefine the same patterns — nothing is more frustrating than having to respecify the details of something you’ve already resolved several times before. And developers are happier for basically the same reason: experiences built with standard components ‘snap together’ in a very satisfying way. End users are happier because they have fewer things to learn in order to be productive with the experience.

For designers, developers and end users standard components and layouts means being able to spend more of your creative energy designing, building or learning to use the stuff that really is and has to be novel.

Despite all this value, designers and engineers often worry about the risk of standardizing too early. I address this concern by making two points. The first is to clarify that the construction and application of standards is meant to be incremental. As a basic heuristic, as soon as you have to do the same thing three times that thing is an excellent candidate for standardization. Secondly I try to communicate that because complexity is expensive (to build, to maintain, to understand, to fix) being biased towards a constrained set of standards is a way to reduce risk.

I’m not always able to sell standards as thoroughly as I’d like. I think this comes from an unrealistic sense people have that value lies in inventing completely new things. Actually, the best value is incremental novelty — something that allows me to build on the skills I already have to unlock a new capability. This is the user-centered route to value and here are ideas about using standards to get there.

• Build a standards culture. A standards culture is one where the default assumption is that for every design project, you first try to find existing patterns to follow before deciding to create new ones. This orientation applies to all levels of structure from visual design to interactions to the data model. Innovation, as long there is a good reason for it, is encouraged, but working with existing standards is always preferred.
• Introduce standards early. From the beginning of every project — including the green field creation of a new product — find and embrace relevant standards. For example, Bootstrap is the de facto standard interface design system for browser based experiences so if you are building one of those, start with Bootstrap. Customize the frameworks, of course, in the way they recommend, but don’t start from scratch with any system component unless there truly is nothing available that meets your requirements. Introducing standards early certainly doesn’t mean things cannot change, but it builds a culture where change is always thought about in terms of a cost benefit analysis relative to the existing standard.
• The design system needs to be documented. There needs to be a dedicated “place” where you go to see examples, patterns and written documentation explaining the current state of the design system. Requiring designers to review the product (or marketing collateral) to discover design standards is very inefficient and frustrating.
• Build the design system in source. The “place” you go to review design system documentation needs to be driven by the same code used in production. The best way to do this is to implement the design system documentation within the production source tree itself. While your staff can explore changes to the visual and interactive design of system elements using non-production technologies (e.g Sketch/Invision or Photoshop), your pipeline from design to production will be inefficient and error prone until you start using pull requests to move approved design system changes into source code.
• Your studio maintains the design system. The design system is a customization layer on top of other frameworks. Your studio needs to have sufficient design technologist resourcing to maintain and evolve that customization layer as implemented in source. There are two reasons why it is crucial for this to be a design studio resource. First, you simply cannot rely on engineering to do this work to the standard of quality you need. Second, your other designers need technical feedback and design critique from a person who can do the implementation and is comfortable communicating in the language of design.
• Your staff can fix UI bugs. Design studio staff needs to be able to fix UI bugs, meaning, at a minimum, issues with styling, layout and interface text. Of course, your primary design technologist resource will have this capability, but there is great benefit in working to build this capacity for all of your designers. One value here will be getting UI bugs fixed correctly and efficiently. But perhaps more importantly, designers fixing bugs improves trust and communication with engineers who will both appreciate the help and feel good about seeing your staff having ‘skin in the game.’
• Teach your standards to the QA group. In my experience QA teams are delighted to include interface design quality in their evaluation process as long as they have clear criteria to test against. You provide this criteria by investing time in educating the QA team in the design system including not just the stylistic details but also the thinking behind the visual and interactive relationships.

Scheduling Expectations

The best — or anyway most important — indicator of whether or not you have a high output design studio is if people think you do.

How do you get people to feel this way?

By doing what you say you will do.

In other words, by being good at setting expectations. Work as quickly and efficiently as you can, deliver the highest quality you can, but never promise something you do not believe you can do. When things do not go as you expected and a designer needs more time than you promised, reset expectations with your stakeholders as soon as you realize your mistake.

Here are the baseline expectations I set with customers of my design studio:

• It takes 3 months to get to MVP for a new workflow. I have found again and again that when the goal is to define, design and build the first working version of a new workflow, 3 months is the shortest amount of time this can be done. Track your projects honestly and you will validate this.
• Every project has a define phase. The define phase is what I call the part of the project schedule in which the stakeholders reach consensus as to the goals and scope of a project. The phase is inevitable, even for small projects, and time must be included in the schedule for it or other dates will slip. For this reason, it is important for the studio to establish the concept of a ‘define phase’ as part of the company planning culture.
• Design and production for a project cannot be scheduled into the same sprint. You need to establish this with project managers as a planning rule. Use the Design Planning Meeting to verify this is always honored after each planning phase. For large projects people naturally understand this, so it with the small projects where you will need to be vigilant. (Clarification: this constraint applies to projects which previously had no assigned designer and for which there is no existing design work — it is not to say that a design cannot be iterated on during development, only not conceived from scratch.)

Integrating with Engineering

At a high level, good integration between your studio and engineering means that the communication channels between designers and developers are wide open, used frequently and working smoothly in both directions. This in turn is the result of positive, trustful personal relationships between studio staff and developers. The single best tactic I’ve found for making this happen is by requiring studio staff to learn the tools and processes the engineers use by asking the engineers to help them learn these things. This forces designers and developers to become accustomed to talking to each other about complicated, technical issues and to develop a kind of camaraderie around the foibles and inefficiencies to do with the established process and tools.

While designers may feel some initial intimidation and possibly even some resentment in that they must adapt to engineering processes and not the other way around, the justification for this is that ultimately the buck stops with developers, not designers. The engineers are the ones on the critical path for releasing code so the ‘best’ communication processes are by definition whatever works best for them. This is not to say that designers can’t try to change the process to make it more collaborative or efficient. However, the first step to doing this is to create trust and credibility with engineering by demonstrating a complete understanding of the process that they have created. You do this like so:

• Use the same tools for tracking work and backing up files as the development team. If the engineers are using Github (actually, is anybody not using Github anymore?) then your team needs to use it too for any file your studio produces that isn’t already some kind of cloud asset (e.g. Google Doc or wiki page). Similarly, if the engineers are using JIRA for tracking stories, then your team should use JIRA for tracking any work that isn’t already part of an engineering story. Yes, your designers will give you a hard time about learning these tools but having your team manage its work with the same tools as the developers will pay huge dividends in terms of opening and maintaining good communication between designers and developers. Of course, you’ll also get really useful benefits like a shared back up repository for assets and a way to track and share work status!
• Assign one of your staff to every scrum team. Being assigned means going to the scrum stand ups, if not daily at least a few times a week, and attending all the scrum planning sessions. Maintain this resourcing even if a particular scrum is “only doing back end work” because it is essential that your studio collectively be aware of all the different development threads that are going on.
• Participate in Pull Requests. The pull request is Github’s invention for discussing code changes and the UX for it is executed brilliantly. The pull request is where the rubber hits the road, where designs become production code and where you definitely have the developer’s attention. Encourage the entire studio staff to watch the pull requests for any project they are involved in (actually, it is a good idea to make scanning them all a daily ritual because you will be surprised at what you learn about what is really going on with engineering) and by all means join the discussion, ask questions, request screen shots, submit screen shots, interact!
• Require that everyone on your staff can build and run the product from source. Not only is this a huge positive for creating technical credibility with engineering, it is also the number one thing you can do to remove friction from the design-to-development feedback loop. One benefit is in terms of building a shared technical vocabulary for talking about the parts of the product — this primarily develops around debugging the instances when the product won’t build or run because one or another dependency is missing. Being able to build and run from source is also a requirement for completely evaluating many pull requests. And it is essential to being able to update code to tweak styles, update interface text and fix minor bugs; things that you want your studio to be able to do.

Integrating with Marketing

Integrating with marketing is different than integrating with engineering for two reasons. The first is to do with the more volatile nature of marketing process: priorities are more fluid, schedules stay in flux longer, and subjective decision factors like emotion and feel are more highly valued.

The second reason is that while engineering teams have little expectation of internally delivering design, marketing teams do. These people have very exacting requirements regarding editorial control and timeliness of marketing output so the idea of letting go of marketing design is scary.

Given these challenges, you sell the integrated structure to marketing by making three promises. First, that you will use high throughput principles to regularize the marketing process, making it more predictable. This will be attractive to the marketing team because everyone likes predictability. Second, you will deliver a service that provides editorial control AND great design. Third, you will be dependable in meeting production deadlines.

Tall order. Here is how to deliver such a high touch service efficiently:

• Assign your lead visual designer the job of managing the marketing relationship. From the perspective of the design studio, the best way to think of the various tactical marketing deliverables is as parts a single, ongoing project: telling your company’s story. Just as you assign a designer to each engineering scrum, you want to assign one designer to the marketing ‘scrum’ even if the marketing team doesn’t self-identify in that way. The marketing team will also be much more comfortable building a dialogue about the relationship between structure and presentation of their narrative with a single consistent point person.
• Make a very specific resource commitment. Describe the relationship in terms of the number of days per week a designer will be focusing on marketing needs. Make this something you can ramp up or down depending on need. In other words, when you know that marketing is focused on a fixed deadline like a conference booth, commit to 4 designer/days per week for the 4 sprints between now and the conference. After that deadline passes, consider if marketing needs can be met with 3 designer/days per week until the next important milestone is established.
• Embrace ready-fire-aim. Marketing is inherently a reactive discipline — no matter how carefully a message is curated, the people receiving it are human beings: capricious, with changeable moods and fascination with fads. Effective marketing — being noticed and understood — means taking risks and changing strategies depending on feedback. Being a good design partner for marketing means supporting ad hoc changes in the structure of the marketing narrative and being excited about finding enchanting ways to present that story as it twists and turns on the path to engagement.
• Design flexible branded vessels for content. People expect other people to change what they are saying far more frequently than what they look like. You want to provide the marketing team with a design system that provides this kind of ‘consistent flexibility’ so that they can use a consistent brand voice to experiment with how people react to different messages. The marketing design system should be optimized for applying standard branding to content modules of different sizes and types. It will need a few interactive elements like buttons, menus and forms, but it will mostly be about defining color styles, typography and a responsive layout.
• Implement the design system in the CMS. Your design technologist and visual designer need to collaborate on creating the style and layout templates that are used by the publishing system that drives online marketing content. If you don’t have an internal technology resource in place yet, then your studio needs to own the relationship with the outside resource.
• Bring in standardized process from engineering. Record marketing design work as Agile stories in the same system of record engineering uses, tracked in terms of the same sprints, with the same planning schedule. Do this even if marketing isn’t already using that system. The value here is to establish stories and sprints as the coin of the realm for a shared planning process. Selfishly this makes it much easier for the studio director to manage design resources but it also makes collaboration between departments easier across the board — an unambiguous positive for the entire company.

Open Issues

I have a couple of open questions that are part of delivering the high throughput design studio for which I haven’t yet managed to develop best practices. I look forward to learning more about these things in future engagements.

• Scaling. I developed the practices I described in this post with a small studio. I believe they will apply well for studios up to ~15 designers. I don’t have experience scaling larger. My hunch, though, is that the fundamental ideas of keeping designers seated together but assigning them to separate projects or scrum teams stays sound always, but that after about 15 folks the best thing to keep communication efficient is to split into separate studios with separate managers.
• Measuring outcomes. I’ve thought a lot about how to measure design. I’ve considered a few dimensions. One is anecdotal: do your customers (engineering, marketing, end users) say you are doing a good job? This isn’t a specific metric but it is important. You can collect it as a rating (e.g. ‘rate your satisfaction with the studio from 1–10’) if you want a number. Another that I think has promise is using story points. There is Agile controversy around pointing design stories so I haven’t actually done this in order to avoid wasting time debating the practice but I’d like to to see how it plays out. A third would be some kind of third party assessment. To some degree this is what user feedback or product reviews provide, but I’m interested in the idea of building process around regular formal evaluations from a paid but objective third party.

Fin.