These are reflections from my personal journey taking the leap from being a corporate designer to becoming a startup founder.
Having worked at some of Seattle’s best design agencies — including being a part of the in-house design teams at Microsoft and Expedia — I’ve experienced some remarkable differences in the design practices prevalent at large companies versus how we ended up doing things at our own startup. Here we go —
Getting people to participate in user research
At large companies, the biggest challenge of recruiting participants for usability testing is finding the right people — those whose experiences and opinions will yield truly reliable data for identifying meaningful improvements to the product.
At our startup, finding the right audience was definitely a challenge as well. But we also had another challenge. Since we couldn’t afford to pay participants, we had to figure out other ways to recruit them. And we did this by telling them our story. This was hard, and took many tries to tell it right. When speaking to an audience you don’t personally know, the way you tell the story is super important. I learned how the same idea can be described in a bland, uninspiring way that leaves people wondering “what’s the point?” or be presented in a compelling way that gets people yelling “where do I sign up?”, or “I need this, how can I help?”.
Once we were able to clearly articulate our story — not too long, not too short, make it personal but also universal, true and authentic — we found people who wanted to be a part of it. They could envision themselves in the story and imagine how our product could integrate into their lives and solve a real problem for them. And they were willing to help us by talking about their motivations, pain points and routines, testing our prototypes, giving feedback, and introducing us to friends with the same problem our product aimed to solve. Investing time in these early relationships proved to be valuable also later on, as these women became our early adopters when we launched our private beta. We believed in sharing our ideas in order to grow, rather than hiding them to keep them safe. We wanted to share new design ideas with early users as much and as quickly as possible — to get them invested in the product, to hear their feedback, and to give them a feeling they are part of this exciting mission. This eventually led to a very personal, true connection with our early users, on a simple one to one basis.
Having someone else facilitate usability sessions
At large companies, even if there isn’t a dedicated researcher, you can find a facilitator (usually another designer) to test the designs you put together. This is important because it helps us remain unbiased. If you test your own design, you might be less willing to admit its deficiencies.
In the early days of our small two-person startup, that was not possible. While only I have worked as a designer previously, both of us were heavily involved in designing the product. This forced us to really think about our test tasks, and focus them on goals users want to accomplish rather than on features. We were well aware to not get attached to any one design or idea, carefully listened to what our users told us both in words and through body language, and were very mindful of not dismissing any complaints as minor or unrepresentative.
When an organization grows in size, internal communication, common knowledge, and decision making — become big challenges. Getting, say, 100 people to agree on something or support some idea typically takes much longer and requires a lot more effort than would be needed for only two or three people. It is therefore necessary for large companies to find ways to make communication as effective as possible. This is a challenge not only because the number of people at the company is always increasing, but also because in large companies employees are divided into smaller teams where each is involved in its own particular set of activities, often not knowing what the other teams are working on. The more the employees are involved in making product decisions, the more they want their product to succeed. One quite effective way of keeping everyone engaged and on the same page is through regular work-in-progress documentation.
At a startup, when the team is still small, it is easy to have everyone aligned, and so in favor of working quickly ‘formal’ documenting is unnecessary. For example, when we started our own startup the very first thing we did after talking through our initial idea was met with our target users. The women we met were very different from one another, and as we continued to build our product we would refer to them often. They became our informal, yet very realistic personas — we felt we knew them, and had a personal connection to them. Whenever we’d talk about a feature, situation or user scenario, these women would be in our sentences: What if a Kristina wanted to share information she submitted outside the app, how would she do it?, or — What would a Lea think this icon represents, how would she perceive it? Being a small startup, we all equally knew these women. Since we didn’t have the need to communicate to others in the company who we were designing for, we avoided constructing personas in a formal way. When everybody knows everything, the need to communicate is reduced to a minimum.
Generalists / Specialists
Both generalist and specialist designers add value to product design teams, but their value is most required at different points in the company’s lifespan.
At a startup (the beginning), when resources are typically quite limited, it’s more important to be able to do a bit of everything rather than specialize in one specific area. That’s why startups value people who have a wide range of skills — one day they can be doing user research, interviewing customers, writing test plans, analyzing data — and the next day they’ll be doing interaction work, marketing, front-end design or product management. The designer’s work, which will still at its core take the role of product design, will also be pushed to expand in any direction the company needs creatively.
Specialists who strive for perfection might slow a startup down, but are very valuable when the company grows.
Large companies often hire experts across many different dimensions to solve any problem the company is having. This is because rather than needing to build as fast as possible to test what works best, they can take more time to build things right for the long-term. And, of course, they can hire a lot more people. For some projects, it becomes necessary to add people who are true masters of their craft. They can bring a degree of experience and domain knowledge to their niche of the product that a generalist could never achieve.
This is not to say that a startup can’t benefit from specialists or vice versa. In the end, the roles of individuals are secondary; what matters is the completeness of the skillset of the team to best help the company fulfills its product vision.
Every design project has constraints, whether you’re doing a redesign of an existing product or building a new product from scratch. What’s interesting is how, at the highest levels, these constraints can differ at large companies versus startups. I’m not talking about constraints that arise from the nature of the product — the people you’re building it for, the devices they use, or the places where they use your product; I’m talking about constraints that arise from the nature of the company the product is being built by.
Large companies became large because they figured out how to solve a real problem for a lot of people. Now these people rely on the company to deliver its promise. Therefore, even if nothing else is a barrier (which rarely is the case, but for the sake of making a point), constraints come from within the reputation and successful brand the company has already built. As designers, it sometimes feels tempting to look at a popular product and imagine how if we just redesign it (with no limitations), the world would be a better place. But in most cases, that won’t work (more about making changes later). The redesign might not achieve the results we had hoped for and mistakes are more costly at large companies because more people depend on them. Therefore, making a better version of an already-successful product or building a new product for an already successful brand — means taking into account the established values customers already have as constraints.
This type of constraint doesn’t exist for a startup, especially if it’s pre-product market fit. A startup at this stage is still figuring out how to create something valuable enough for people to come back to.
It may seem like design at the very early stages of a product is way more liberating — you can invent new design patterns, choose whatever color pallet you want…. But — A startup is constrained by money, which trickles down to everything else — intense time pressure, not enough experts/knowledge, human resources, etc. These constraints force founders to prioritize on every level. You can’t delegate tasks to different people (marketing, social media, content writing, etc…), because there aren’t nearly as many people as there are tasks. At our startup, we didn’t have a technical partner at the beginning, which meant we had to pay someone to write code. And not having many financial resources meant we couldn’t just build every new idea or feature we thought about. This constraint led us to make many, many prototypes, constantly engage with users, and test our designs, again and again, to understand what is working and what we need to continue iterating. Only then we prioritized what we should invest time and money developing, and when.
Making changes to a design
As designers, we look at how people use our products and find opportunities to make them better. However, making changes can look very different for a mature product compared to an early stage product (in particular if it’s pre-product-market-fit).
Large companies are more risk-averse, they are careful not to mess up what’s going well, and won’t easily make big changes to what put them on the map in the first place. Yet change is an essential part of the evolution of a product — a product that doesn’t change will fail to match the advances taking place in how technology is used. That is why many good companies find ways to make changes as embraceable as possible for their users.
Startups take big risks and change things constantly. At the early stages, when the company is still searching product-market fit, most change is a good change. If you launch a product and people don’t care for it, making small tweaks won’t make a difference. At our startup, there were many times that we knew we had a problem to solve but didn’t necessarily know what needs to change to get it fixed. So we’d break things constantly, and redesign again and again.
One example was users behavior right after signup. A small percentage of users signed up, and then left. They made the effort to put their foot in the door (which really was an effort considering the only way to enter required remembering your Facebook password) and then wouldn’t stay to look around. We had assumptions for why this was happening, but couldn’t know for sure what was causing it. We also couldn’t authentically recreate the scenario in usability sessions, because by being there next to a user, it was unlikely for her to leave right away. Even though this problem only affected a small number of users, making big design changes was necessary, sometimes just to the on-boarding flow and sometimes to the entire product. A few reasons made this necessary — 1) we couldn’t know exactly what caused people to leave so we couldn’t just change one particular thing and call the problem fixed; 2) one change in a product almost always leads to more changes, as the app is thought about holistically, not individual pieces; 3) we wanted a solution that’s leaps and bounds better than what people use today. As a startup, even a few users can teach us a lot. Those who entered and then left didn’t get what they were looking for. For us that meant our solution was ok, but not great. And we didn’t want to be ok.
Feedback and critique from other designers
Critique, and designers giving other designers feedback — is an important and effective tool for improvement. And even though it’s not an objective tool (other designers are not our users), it’s nonetheless an important one. If a designer is working alone and never showing their work to other designers, in most cases their work won’t be as strong as if they were engaging in regular feedback sessions.
At our startup, not having a team of designers to consult with was one of the things I missed the most. To make decisions we relied on usability sessions, user feedback, quantitative data and good judgment (we were users ourselves), but not so much on feedback from other design professionals. I did get feedback here and there showing designer friends what I’m working on, but it was never on a regular basis. It’s a scary feeling knowing you’re the most experienced designer in the room, making decisions that can make or break everything. But I learned that if you can push through this feeling, and understand you can and should take a risk, truly incredible things can happen.