Designing in Small Startups
We use to read a lot about UI/UX and product design in successful startups, tech and digital product companies. But, those who have been working for a long time in this market know about all the mishaps we endured before being able to be a part of the big projects.
Being a person who is passionate about new ideas and about opportunities to bring them to reality, I always looked forward to being involved with projects that allow me to develop innovative ideas, learn and express creativity. And here is the trick. Usually companies with these features are those that are starting out, small businesses in their initial state.
What I want to address here are the challenges we as designers and engineers have in startups from the beginning. Not all of them have that initial million dollar contribution, when have some investments that aren’t from the founders. Beside that, there is a necessity to have a scalable, fast and efficient product. This is more than necessary, but mainly urgent. And “urgency” is the word that drives the need to develop within any business in its initial state.
Our metrics are our experiences
The urgency state that involves all small business is even more aggressive within the design and engineering teams. It’s through us that the product is actually born. If there is no product, then there can be no sales and when there are no sales, there is no company.
With no time to plan, design and test properly we become hostages to what I call “splash and go”. We deliver the task and move on. Because of this practice, the chances of delivering the best product in an efficient way with high quality decreases drastically.
To achieve agility and meet the needed deadlines, we turn to our professional baggage. Many times our experiences in previous jobs and from other avenues such as research, books, articles and our ability to understand the project’s complexities are our only available tools. Without resources, relevant data and other information, the only thing we have as concrete is the actual idea.
Certainly all of us have experienced this truth. We create with limited data, a ton of passion and end up with results that leave us with the doubt; “Could it be better?”
Yes, it could, most of the time.
We test with no time for tests
When working with and creating websites in beginning of the 2000s, we were all web designers and didn’t have all the current methodologies, metrics, test A, test B, test A/B and tests of usability at our disposal. The process in that environment under extremely urgency is quite similar to what we experienced at that time.
The trade of ideas and information between our teams and colleagues are our main source of answers about what we’re developing. We are all users, clients, and listening to each other help us at the very least what not to do. If among your colleagues or social circle there is someone within your target profile, engage with this person. He or she might be one of the only validated sources of user information during the creation and development process.
Far to be a good thing this is the reality. We run tests during creation and, validation is established at the same time as development of the system functions and designs. During all this, time is still running.
Not all of the information gathered throughout the process will be used, but it will be extremely useful to at least cover some gaps.
We launched the product. What comes now?
Here we are with the product running and the activated users. There were delays, we needed to re-code some lines, review some of the functionalities, lost time where we could’ve gained some if we had the opportunity to plan each step properly but the product is on the street.
The true testing stage starts now!
When developing a project based on recurrent usage, we know that it will never be totally ready, but in this case your product actually has been launched not being.
The agility we had with the development needs to be even more present when the bugs start to appear. It’s inevitable. They will happen, they are there. But the main issue is starting the analysis process regarding user behavior and if in fact the solutions are efficient. It takes only a few weeks to understand what should be improved and if we have enough users to provide us with the data we need. Our team might be able to make the adjustments in the necessary time. It’s a race against time and it becomes worse when we think about how small our team is.
The secret here is to prioritize what really impact the user experience, what gives a negative perception and the causes for deviations. Users are essence customers for recurrent products, and because of this, the demand for quality is even greater.
We need to quickly identify the critical points and to implement the solutions as swiftly as possible. Usually, this is the PO’s task. When there’s no PO on your team, the design leader remains responsible for this. It can seem smart but its leg work lost in the design process. Furthermore, other expertise such as engineering seldom participate in the process and are just notified of the changes with no time to discuss or think about the changes. In this, they are losing the opportunity to bring better solutions to deploying the adjustments.
The only real advantage of being in a small startup is that your users start in dozens rather than the hundreds. But even so, there are enough of them to give us a decent amount of data to enable us to step in and in the end, the impact of the failures are smaller. This will enable us to remedy the bad experiences with less trouble.
More resources, less experience
In due course, the product starts to become what should be. The issues are resolved and the growth process starts to happen thus decreasing the urgencies. The bad experiences we walk away with from the stress of the development process affect us both professionally and personally.
Despite that, our experience and learning curve is extremely vertical. I believe we learn better with trial and error. The hits are important, for sure, but the mistakes will help us to do better in future projects. The adaptation process gives us enough experience to find some short cuts during the next project and avoid issues that before were inevitable and difficult to predict. Thus, we can assume that more resources we have, the less vertical our learning curve will be.
In the end, despite all the learning, a more controlled environment and with more resources is more efficient and pleasurable professionally and personally. There are people who like this extreme pressure and urgent mode of production, but let me give some advice; with more resources, experienced colleagues and an environment with diary of learning curves to consult, your quality of work and professional development will benefit exponentially. This is in addition to improving the delivery of your product.
We will not always find the ideal environment and we will almost always start in small companies, full of problems and failed processes, but those are the ones that will give us more experience and will prepare us to play in the “big leagues” in a more efficient way.
For me this is a natural process in our professional development as designer that provides us with knowledge of what is good or bad for ourselves. As I have said, I’m a person that like challenges, innovation and usually will be involved in problematic processes, but not everyone is willing to substitute the quality of the creation process for that. There is no right or wrong way; these elements go hand in hand. The important thing is to believe and to be happy with what we are designing.
I really hope you liked my article! And if you have seen yourself in some (or in all) of the situations described here and if you want to share some stories, comment below. Let’s share our experiences and suffer together.
