In my last post, Giving UX and Design Advice, I started talking about a buddy of mine asking me about design support in incubators and described what goes on in the mind of one person (me!) who gives design and UX advice. I believe this gives clues as to how to find a person to fill the role of a design/UX advisor, or if someone wanted to become one, what they might expect.
Let’s get on with the real topic, which is, if you’re running an incubator, should you provide design as a central resource? And if you do, how might that work?
Also, when I say incubators, I think that we can include any investment operation, such as a venture fund, who wants to provide centralized design help to its portfolio companies.
The Problem Statement
There is recognition that for early stage startups, getting the product right has unprecedented importance over other aspects of the business. If this is true, then getting the user experience of the product right is paramount. Assuming we know the difference between design and UX, design has definitely the user facing component of the user experience of a product. Thus it’s natural that helping startups find great design support is very important.
The problem with finding design support is that…there just aren’t enough great designers around! The world simply doesn’t have enough designers who are talented AND are great at crafting a great front-end user experience. Note that you can’t just have someone who is talented because some guys are just not good UX people. So if we’re lucky to find a great designer who is also a great UX person, then we’d want to utilize this person on a wide variety of projects.
However, in what form should the design/UX help take? Advice only, or actual work? Here are some examples of this in the real world now.
The Designer in Residence
About 5-6 months ago, the world saw its first Designer in Residence (DIR) at Bessemer Venture Partners. The term was first coined by Bessemer’s David Cowan and shortly after the Mint acquisition, their designer Jason Putorti became the first DIR. I have talked with Jason about his experiences as a DIR and will wrap in some thoughts from conversations with him and Bessemer folks. For a more in-depth look at his experiences in his time as DIR, please look for his upcoming post at his blog.
The main purpose of the DIR was to help out the Bessemer portfolio from a design point of view. Any portfolio company that was receptive to help would get time with Jason, although it was mostly from an advice point of view. The startups that were receptive to outside advice really appreciated his visits and comments. Many startups did not feel the need to receive outside help and some of those probably didn’t need any design advice, and some, by some viewpoint, probably could have used some even if they didn’t think they needed it.
That’s not to say that Jason didn’t deep dive; this did occur but it didn’t happen very often since his time was limited with each company.
Betaworks
As part of our operations at betaworks, we incubate some businesses. Thus, providing design help to our internal projects was deemed critical to getting those internal products out the door quickly and allow us to iterate on them, without having to waste time to find design help for every project. We hired a designer to be on staff to help us work quickly on our ideas.
In the case of betaworks, my proposed problem statement is not their main purpose for having the designer on staff; this designer actually does the work, and so therefore his time is limited because he needs to focus on projects to get design work done. Currently he works on 2-3 projects maximum, and at any one time is focused on one.
He hasn’t done much at giving design/UX advice though, simply because his time would get overwhelmed helping too many people at once, and then only at the advice level.
He also has noted to me that he has extremely enjoyed the interactions and the projects, and the wide variety of problems to solve from simple sites to complex services. Such is the nature of working for an operation whose day to day interactions are always with the latest and greatest!
Parallels with Central Design Teams in Bigger Companies
The issues experienced, when attempting to provide actual work, mirror those of companies with central design teams attempting to service many teams at once. Because the teams do not have dedicated design support, they have to come to the central resource to get things done.
The typical issues encountered in these situations are:
1. Competition for design time, and the resulting tensions. Sometimes there is the threat of going outside the company for design help, which works for some companies and is absolutely prohibited by others.
2. Accounting dollar-wise for design time can be challenging, and things such as chargebacks to matrix headcount attribution have been tried to account for resourcing, and to see how much design time and cost a project has used.
3. Headcount is always an issue, and fighting to add to headcount in a central organization when it’s not tied directly to any revenue generating project (instead, it’s tied to all projects both revenue generating and losing) is a difficult fight to win.
4. Designers in these central teams are often stressed to finish way too much work and quality can suffer if the demands on their time exceed their ability to finish quality work.
5. Causing 4, scheduling projects is always a problem when so many people are vying for your design time. Prioritization is always an issue, and frustrations can occur when someone doesn’t get support when they need it.
Provide Only Advice, or Resources to do the Actual Work?
Here you go, the pros and cons of both!
Advice Only:
PROS:
1. Can handle a lot of projects at once.
2. Can talk about issues larger than just design alone, that are related to user experience.
3. Breadth of exposure to many projects gives a breadth of experiences to bring to bear on any one given project.
4. Effectiveness is potentially at its greatest at the certain stages of the project, like at the beginning during product definition before decisions have been made, and evaluating what has been done already, especially if there is evidence that there are problems with what has been launched and receptiveness to help from the team is greatest (since it’s obvious there is something that needs to be fixed, rather than not having concrete evidence before a product is launched.
CONS:
1. Only helps those who are receptive.
2. Even receptive people may ignore your advice, or simply forget about it later.
3. Advice can only be implemented if the team can internalize what is being said. If they do not have enough depth of understanding, they may not be able to implement fully, or only partially which may not be enough.
4. Lack of depth on a project can result in incomplete advice.
5. Advice can be wrong, or simply wrong for a given team. The right solution for a given problem may come in a multitude of forms; the advice a single person gives really only offers one solution but it may not be the solution that a team requires to get to success. Remember that success can come in many forms. For example, even if a product has a terrible UX, if the startup is sold and investors make money, then by many measures, the startup has reached a success despite ignoring UX advice.
6. Giving design/UX advice requires an individual who enjoys giving advice as a career and not doing the actual work. It may be hard to find skilled individuals who want to give advice and not do the actual work.
7. Giving design advice is only part of the solution; we still have to find someone to do the actual work. Designers are still hard to come by. Without anyone to implement the advice, the advice may be pointless.
Doing Actual Work:
PROS:
1. Inserting a great designer is the best way to ensure that the right design work gets implemented. Having someone on the team who is there, fighting for the right thing to do 24/7, is the best way to ensure that a great UX gets launched. It also enables depth on a project, so that the probability of the right design being implemented is greater.
2. Evidence has shown that most designers love doing the actual work, and that it is much more satisfying than just giving advice. So it’s most likely easier to find designers to staff a central group that does work.
CONS:
1. Coverage of projects is extremely limited, often only one project at a time.
2. Since coverage of projects is limited, you need a lot of personnel to cover a lot of projects. Paying salaries for all these folks and supporting them can be a challenge for an operation that does not have recurring revenue (ie. a fund or incubator is not a business with revenue). Or do we charge our startups, which has its own issues given that they are most likely early stage and very sensitive to expenses?
However, if the entity that provides design support has deep pockets, then either design support can be provided for free, or at a steeply discounted cost to the marketplace.
3. Running a central group which does work is like running a design consultancy. It will have the same issues as any consultancy in managing the work and client. Having worked at frogdesign, I can tell you that running a consultancy is not an easy thing; keeping deliveries on schedule, maintaining happy customers and quality of work all takes experience.
4. How do we know that the designers on staff can maintain quality? What if the best design support can be found outside the central group? What if the design talents that the startup needs are not found within the group?
5. Finding designers to hire is still tough. How much time is required to even build the team itself?
6. Central group design support is still very discontinuous; the group comes in, does work, and then stops for a while. In the space between projects, a lot of learning is accomplished which may not get back to the designers. At some point the startups will require their own dedicated design help which is continuous and 24/7.
One might notice that in either case, the list of cons exceeds the pros. I would say that the brevity of the pros doesn’t minimize their importance. Each of those pros has tremendous value for each path. It is the cons that we must watch out for and be OK with, when setting up design support for an incubator or fund.
Footnotes:
a. As I was finishing up this post, I got word that the venture group at Google provides design support on contract, and on a limited basis to its portfolio companies. I hope to meet with the designer to get his take on how this works and how it’s going for him.
b. One of my reviewers pointed out that this post ended kind of open ended and left him feeling the need for some firm conclusion. Yes I bailed on giving a specific conclusion because I believe that the direction an entity takes is highly specific to the situation and its own needs. I do not think there is one size fits all in providing either type of design support. I wanted to point out what the pros and cons of each direction were, and let the reader create his own solution based on his own requirements.
Many thanks to James Cham @jamescham, Jason Putorti @novaurora, and Neil Wehrle @neilw for reviewing this post!