UX UI design for startups in real life

Coming from an art and design academy I was very eager and naive about design processes in general. Working at design agencies shattered my academic perception of the design process. After a few years in different design agencies, when I switched to startups and digital product design (aka UX UI) I’ve noticed, again, that I have to adjust. It’s completely the opposite of what I was taught in the arts academy. It also differed tremendously from design and advertising agency approach to things. It was a bit crazy, very interesting and constantly changing. It was really hard to digest, agree with and implement at first, but getting to know the people and the goals behind every decision helped me adjust, my designer-ego was tamed and I now feel competent to write about this, so here goes.

Startups vs agencies

In a design agency, the product is design itself. In an advertising agency the product is the marketing message with a design “sauce” all over it. This is great and very clear to those coming to an agency to become a better designer or art-director. However, in startups this is different. Here design is not a “sauce” anymore. It’s a mandatory and integral part of the product. The product (app, website, e-shop or web-interface) need to appeal, it needs to get the user’s attention and solve their problems. That’s why it’s crucial to have design integrated in decision making, including strategic and tactical development of the product. As a designer you should attend management-level meetings that have to do with project goals, development, marketing strategy, audience etc. If you see that the next planned feature will not add to the overall experience — you should point it out. If you think that a feature next in line is TL;DR or not interesting to the user or just plain boring — speak up.

Working in a lean/agile environment in a startup

Most startups today, big and small, tend to work according to one of the methods — agile or lean process of development.

These allow fast delivery of a product upgrades and testing in real life what works and what does not. As a designer you will be the first to know of the coming features and the first to make appropriate design changes. Usually the rush and craziness of scrum and two-week sprints of development don’t affect the designers, but sometimes they do, so be prepared to stay extra hours sometimes. This is what a startup is all about — making fast movements in a fast-paced market.

Working in a monetizing startup

At one point or another a startup decides it’s time to monetize. When this happens — priorities start to change from the head (CEO and stakeholders) down to focus on BI, metrics, advertisement, optimization etc. All tasks go through “will this bring in cash?” filters.

When a designer is summoned to solve monetization tasks — always do involve a marketing specialist and don’t try to take it all on yourself. You are not a marketing specialist (unless you are, then ask for a double salary), and marketing decisions cannot be your sole responsibility.
 Tasks in a monetizing startup become more repetitive and changes more subtle, up to a point when it seems like everything is about money and not users, which made me personally feel uncomfortable.
 With others this period may be a time to chill, recharge and focus on productivity and technique.

Delivering faster

All startups are different, and each one strikes as a completely different challenge. But most of them do feel like a race.

As much as I love to do the classic design process for a product–it almost never happens. Usually the client appears with half-done design. Sometimes they come after a really bad experience with another designer. Sometimes they did the whole design DIY for a year or so and it looks like a disaster. Many times the client has no idea what the difference is between UX and UI. The list goes on, but the message is–don’t expect perfect because there is no such thing in this field. Expect interesting stories and business ideas. Expect ground-breaking technologies. Expect big missions like making smart cities or solar power plants.
 As a freelancer and an employee in a startup I always arrived at different points of the product cycle. Sometimes there where wireframes ready. Sometimes the brand was in the middle of a redesign process when the previous designer suddenly left. Many times there already was a working prototype or live product which I was asked to “make look good”. As I said before, most tech people do not distinguish between UX and UI and tend to mix them together when discussing or requesting a design solution. So a good designer listens, figures out what the person describing the problem actually means to convey and then uses the needed tools to solve the problem. Do not try to focus and adhere to the classic “design thinking” model, it does not work in the real world of high-tech, instead focus on one task at a time, make sure you do see the whole picture and try to get results fast mostly relying on your gut feelings.

  • When a new widget or another small improvement is requited it’s OK sometimes to skip wireframes. Its is a great idea to whiteboard wireframes during a feature discussion, then take a photo of the board and work from that as a guideline to a final design.
  • Use pre-made icons from different icon-sets, stock images, templates and anything else that can shorten your delivery time. You can finesse the details later when the design is approved, and even some parts can be changed in the middle of development.
  • Use the “style you like” queston when you are not sure about clients’ preferences and don’t have time or budget for multiple design sketches.
  • Good artists copy, great artists steal. Using solutions from someone else’s design work is OK as long as it’s not a total rip-off
  • When a design does not translate well to development and looks off–sit down next to the developer and explain in words what you meant to happen on screen. Personal communication solves problems way faster in this case.

Where is that fine line between rip-off and inspiration–everyone should decide for themselves.

Leading the way

Many may not know it, or agree, but design actually defines the product and dictates what the development should or should not do.

This does not mean you get to boss people around. This means you need to develop communication skills and persuasion to be able to talk people into what you want, why, and how it will benefit the company goals.
 Developers and designers alike are rather lazy people, so you will hear a lot of “but it will take me a long time to implement” or “can we not do it, I already have a ready solution for it and it works just fine”. See, developers think in terms of “working vs not working”. They are engineers by their nature, and it’s a good thing when the product works. But, there is a but. If a product works but is uncomfortable for the user — it will not be used. It will not get popular, it will be neglected, the firm will lose clients, money and investments. Plain and simple. So the designer in a startup is an ambassador of good design, usability and the voice of the user in general. It’s OK to go against management about this too — just do it tastefully and rationally explain your decisions and concerns. Emphasize the user-friendly, user-centered and conversion/audience gains that your suggestion will bring, and management will listen.


Working with startups is a unique experience that can take time to get used to. The environment is dynamic, the deadlines are tight and sometimes is seems like no one is listening to you. Having said that–there is nothing like being part of something new and groundbreaking, feeling the passion and the desire to make it in the world, absorbing the fighter spirit and sometimes dealing with spartan conditions. The lessons learned from a startup world cannot be learned from anywhere else, and this definitely is a worthy ride. Keep cool, develop good communication, always try to attend as many meetings as possible to understand the strategy and goals better and you will be just fine!

Originally published at marklevi.com on June 9, 2017.