Beyond Aesthetics —
Design Principles For Startups

Thomas Petersen
Black n White
Published in
8 min readAug 31, 2015

Don’t panic!

This is not going to be a lecture on typography or color palettes and it’s not going to require you to have the latest Creative Suite from Adobe. In fact, you don’t even need to be a designer or UX expert to use any of these principles.

Instead I want to try and get you past what UX, designers and other experts think and give you some principles to work with.

So what does it take to design a successful product or service in a startup?

Is it the brand? The choice of colors, the functionality, the language, the platform or network effects? All of the above certainly have some importance, but it’s going to be very hard to insist that one particular element is why a company is successful.

Yet all too often we become attached to this idea that there is a recipe for success. That if you just get the right concept or your design is beautiful and uses a certain technology, you will be successful.

Nothing in my experience, supports that belief. In fact there are as many roads to success as there are to failure more over — what mean success for one company, might spell failure for another.

WordPress.com is based on PHP, a server side language that many “real” developers loathe. It’s not a real programming language and that it doesn’t scale well. None–the–less a whole plethora of successful companies were originally based on PHP, including FaceBook, Flickr, Magento and Yahoo.

Google wasn’t exactly used to win design prizes for their look and feel. Yet they were so successful that they established their own aesthetic. Today companies are trying to look like Google.

Hulu.com was a success long before they started adding social features. Joost were designed primarily around social features but never made it off the ground. In other words, what make something a success has very little to do with any specific prioritization.

How are startups different?

When you are building a startup, one of the most important things you can learn is how to prioritize. If you are a first time founder the main challenge you are going to ask yourself is who you should listen to. Designers are going to make you want to prioritize design. Developers are going to make you prioritize technology. All of them have really good arguments for why they should be prioritized.

Large organizations can afford to prioritize many different areas at once. To them launching a product is itself a sign of success almost no matter how well it does. They have the money to continue down a dead–end and will invest millions in doing all the right things from research, usability tests and 5 different design proposals, to establishing brand guidelines or build a customized database protocol and then launch something, two years too late, to great fanfare and often, into great obscurity.

If you are a startup you don’t have that luxury (or shouldn’t have). You wont be able to spend that much time and money building spaceships no one want to fly. You need to prioritize.

One of the hardest parts about being a founder of a startup though, is to figure out how much importance you should put on the different things. How important is design actually?

My general advice to all the founders I have worked with have always been the same:

Get to the point where you have real users or customers as quickly as possible. It’s these users that will provide you with the necessary information, to make better design decisions and help you prioritize.

Of course the problem with this advice is that it leaves out how to get to that point. So normally would have a chat with theses startups to help them get the most out of design using the least amount of resources. I can’t do that here, so instead I am going to distill these chats into what I consider to be some principles that, if applied properly, will help you get to your first customer.

Start simple, stay simple.
It cannot be said enough. Less is more — much more, and there is a very good reason, which it pays to understand:

If you do less you can measure more. If you can measure more, you can better experiment with what works.

Most products are simple, based on simple insights.

Make sure that you stay true to those insights until you know you explored every avenue. Don’t add new features just because you think that it will help you be successful, it wont, not yet at least. If your product becomes a success, it’s not because of how many features it has but whether you found a pain point for your customers.

Don’t confuse change with improvement.
One of the biggest challenges record artist face when producing a new album is listening fatigue. They get this from listening to the same riffs, passages, drum tracks, choruses etc. over and over and over. It’s actually one of the reasons why many of them have a problem listening to their own album, when it’s finally done. Startups as intense and time consuming as they are, have similar problems. It’s very tempting after a couple of months of looking at the same design, to want to change it and think you are improving your product. You aren’t, so don’t succumb to the temptation. It’s not worth it.

Furthermore, if it goes like it does in most cases, you will soon enough have to spend resources on changing things after you launch. Resources that you just wasted on thinking you improved you product.

Build to integrate.
Think about whether your product could be a good extension to already existing products/services. That way you can tap into already existing ecosystems to leverage their popularity. Remember that the more you are able to interface with other services the more trust you will establish. Guilt by association works both ways. This shouldn’t be confused with building on top of other ecosystems (sharecropping)

Don’t do everything that is possible only what is necessary.
Constrain yourself. A good product has limitations. It doesn’t succumb to every temptation that comes along. Focus on what makes your product the product and only add features if you get a clear indication that it is needed.

Your customers hasn’t spent months playing around with every aspect of your product, so don’t try to impress them with features before they understand what your product is all about. Spotify has many flaws, Basecamp leaves a lot to be asked for. But when all is said and done, their products are rock solid. And there is no feature like the rock solid feature.

Don’t ask for user feedback, create meaningful feedback loops
It’s one thing to ask the users what they think about your service or product. But trying to build products by looking to users to test your product before it’s an actual product, is meaningless.

A common misconception a lot of startups have, is that you should test your product on your users before you launch. The belief is that it will allow you to catch some of the worst mistakes before you launch your product. Don’t believe the hype, I say this as someone who used to make a living doing usability tests too. There are situations where usability studies make sense for startups, but most likely it wont be in your situation.

I wrote a separate post about User Centered Design, but give you a few reasons for why you shouldn’t waste resources there.

In most cases where you do usability testing, you are testing in a pseudo environment with mock-ups, html prototypes or even paper prototypes. Just imagine how Twitter, SMS, Google or Facebook in it’s early days would have scored by the standards normally applied.

Unless you are inventing some completely new interface paradigm or a new input device where you are looking for the optimal version, chances are someone else have already solved it for you. Use it, stand on the shoulders of giants, there is no shame in that.

So many products and services need to be experienced before users will provide you with any valuable insights to build on and even more will only show you valuable data if you have a lot of test-samples. It would be like trying to determine the usage and usability of a hammer by looking at a piece of paper with a drawing of it.

A feature is not a product, a product is not a business
Speaking of hammers — Don’t just think about your product as a bunch of features. Instead focus on what it is your are selling at it’s core. What is needed for your product to function? How much can you take away from it without sacrificing the core product.

Think about features as something to add after you have launched.

A hammer has one purpose, which is to help you knock in nails. Everything on top of that is features. Therefore — understand when you are working on your core product and when you are working on adding features.

The benefits of thinking like this, is that it will help you establish a very clear an precise picture of what makes your product your product. Which means you will much better be able to understand why you are adding features when you are and won’t get caught in the “me to” behavior that can drive companies out of business very fast.

Think how, not what.
What matters is not what functionality your product has, but how it works. A sign-up process is not just a sign-up process, a checkout process is not just a checkout process, a button is not just a button, a rating system is not just a rating system.

Think about how you can stand out by introducing something that everyone else might have but in a unique way. That’s what Steepster did when they re-designed their rating system (se how they did here). Skype was not the first VOIP provider, far from, but Skype managed to make it stand out and look like a product not just a technology. In other words they productified a technology

You will be surprised how much the “how” can help improving your product.

It’s not innovation to use the latest technology.
It’s tempting to try and set yourself apart by using the latest build of some framework or technology. But don’t do it just because it’s the latest. Make sure that you understand the implications of what you are introducing. Is it processor intensive, is it increasing load time, does it improve the experience, is it understood by enough developers so that you can optimize it.

If you can’t answer the above, you probably shouldn’t do it.

All to often companies get caught in thinking that new technology in itself is the differentiation factor. But as most successful businesses know. Innovations have an introduction curve and not everyone should take advantage of a given technology just because it’s available.

Thats it…

As with everything else here in life, the real challenge isn’t to figure out all the things you want to do, but what you want to spend your time on. Building a startup is no different. Hopefully these principles will help you better understand how to apply design to your situation. If you have some other principles I would love to hear about them.

If you enjoyed this essay you might like to recommend it,
sign up to my newsletter or support my app.

This essay was originally published on Black&white in 2010.

--

--

Thomas Petersen
Black n White

Head Honcho at Faktory.com Investor, designer, tinkerer. First Principle founder. Square, 80/20, MetaDesign alumni. Hello co-founder, Dotcom survivor