Transforming workflows
Creating new and updating outdated processes
Officially, our main task was to design a new product. Nevertheless, it was evident that we needed to set up proper processes to build a decent product.
Changing the way of thinking
When we started, the product didn't look like a product. It was a set of features barely connected to each other. Another obstacle was that there was only a project manager (focused on the execution) and not a product owner (focused on the value).
We started by changing the approaches of the project manager and the CEO.
In parallel with our design tasks, we talked with managers about the product and how we should build it. Every few days, we met and talked for hours. We made presentations, discussed job stories, shared other companies' experiences, and asked "Why?" many times.
It took us months, but we managed to shift their perspective. Moreover, it was so successful that they became advocates of the best design practices.
During our work, we repeated this education with all new managers. It was my main challenge because it required a lot of energy, was emotionally challenging, and needed time. Nevertheless, it paid off immensely.
Educating through integration
Everytale team wasn't familiar with most design approaches, so we had to introduce and then integrate these approaches into the company's processes.
We started with the simplest: prototypes. They always look impressive, and we needed to show them just once so everybody liked to use them. Later, we used prototypes for all kinds of tasks: quick idea tests, explanations for engineers, usability tests, presentations, etc.
Jobs to be Done framework was the next on my list.
Despite their seeming simplicity, writing job stories is hard. We started by writing and rewriting top-level job stories on my own, spending a few weeks on it. After we were happy with the results, we began discussing stories with the rest of the team.
After a few more iterations, the stories were ready. Interestingly, top-level job stories changed once or twice a year because our product and our understanding of what we were doing changed.
User interviews started as random events and became more structured and systematic over time. The Biz Dev team conducted most of the interviews, and designers attended them periodically.
The Biz Dev team was proactive in their interviews but still needed a bit of guidance. We gave them a few lectures about JTBD (what we really wanted to know about users and some user interview tricks).
Integrating metrics can be tricky. Connecting a tool like Google Analytics is extremely simple. The problem is that if you don't have at least a few thousand users on your platform, all the data will be statistically meaningless. With that in mind, we waited until we had the required amount of users.
In addition to standard tools, we found a new startup that unusually visualized statistics. It built a statistical model of the product and visualized it as a probability graph of how a user will move through a system. This allowed us to identify a few bottlenecks.
Using quantitive tests was difficult for an unexpected reason. The price was high for a small startup, so we used these tests only for essential parts of the system when we had a few equally good ideas.
A silver bullet of intra-company communication
Communication is one of the most critical activities in any company. We wanted to set up a process for constant communication between designers and the rest of the team. There were a few obstacles in this way:
Some engineers didn't believe that meetings were useful
The Biz Dev team and stakeholders perceived meetings as a way to ask for more features
The whole team was spread from India to the USA
Some engineers didn't speak English
We found a solution (Design Syncs) relatively quickly. The idea of Design Sync was that every Friday, one of the designers prepared a simple presentation that described all the work designers had done during the previous week. Design sync pursued a few aims:
To inform developers and business teams about features that are currently in design
To get feedback from developers and business teams about the most efficient ways to solve problems
To collect ideas from developers and business teams
To better synchronize designers with each other
Design Sync has always been a place for me to experiment. In addition to the primary purposes, we experimented with it:
Made it more attractive for the presenting designer through a unique cover creation
Minimized preparation time through a template and collaboration
Used it to train designers in public speaking and English
Added demos, surprising interactions, games, etc.
It certainly took time from a designer whose turn it was, but it greatly paid off with tons of ideas and feedback from the rest of the team.
From a feature-factory to a product company
It's terrifyingly easy for a company to become a feature factory. When you think about a product 24/7, it's way too easy to get the impression that only a few new features separate your product from success. Every team member is susceptible to this bias. Sadly, Everytale didn't become an exception.
As soon as we mentioned it, we started to discuss it with other managers individually to understand their points of view. The problem turned out to be even more complex than it looked. Problematic directions we found:
Stakeholders suggested ideas without a complete understanding of the product and our audience
The Biz Dev team requested to implement every improvement our potential users asked about
The design team tried to implement the best UX solution even when expenses were higher than profit
The engineering team implemented half-baked functionality to meet deadlines and never finished that functionality
The product owner forgot to put already designed features into a sprint
To fix the problem, we suggested a process of adding tasks to the backlog. We presented my concerns and ideas at an all-company meeting (including stakeholders) and got approval. The algorithm wasn't new, but it legalized and structured actions we were already doing and provided a common product understanding base.
Because of this process, many irrelevant ideas weren't added to the backlog. Nevertheless, we wanted to save the dropped ideas.
All of them were still useful and collected in an idea pool. When people are excited about a product, they suggest ideas all the time, and there are a lot of good ideas. However, they couldn't be implemented immediately because of the current priorities and plans.
The pool was a collection of structured ideas. When designers started working on a new feature, they checked the table and used all relevant ideas.
Evolution of design files
Things get more complex when there are five designers and a product swiftly changes. Just a few examples of such challenges:
Figma files were getting too large, so they had to be split
A system is so fragmented that some pieces are hard even to find
Some features are implemented, some aren't, and the only source of truth is the system in production
There are multiple versions of the same feature. Some mockups are changed during implementation
We used several ideas that have been working on different levels to simplify the work process.
Project level: three types of files
File level: mockups versioning
Every file represented a corresponding part of the system. Every page of the file contained a full version of that part, corresponding to a particular sprint. Such structure provided a list of advantages:
Everybody could always easily find complete and latest mockups of the system
Engineers could be sure that mockups wouldn't change even if a new feature were added to the same part of the system
Designers could easily split complex feature implementation into multiple phases
All mockup history was easily accessible
Page level: mockups in workflows
Organizing mockups in workflows is the only way to make them easily readable. Otherwise, it takes a lot of effort to spot differences and to understand the logic.
Bonus level: interface texts
Usually, startups don't think about or even mention how they manage interface texts. In a small product, it works on its own. There were two nuances in my case:
We updated a lot of core terms
The product supported four languages
Just imagine that you need to change one word that is used in 30 places all over the system (in titles, filters, descriptions, etc). And the word could be in four different languages. And a few words should be updated simultaneously as they are tightly connected.
We researched all the tools that a small company could use and concluded that Google Sheets was the best option.
The table contained different variations of texts:
Initial variant (written by designers)
Change suggestion (for edits from native speakers)
Approved variant (designers decided if they were happy with the suggestion)
Renamed variant (due to the high volatility of a startup, sometimes terms change)
Production variant (what's in the product)
Findings
There isn't any foundation you can rely on. It takes a lot of work to set up processes from scratch. The good thing is it becomes easier after the first step.
Nobody can tell what is right and what is wrong. You have to take a lot of responsibility and be ready to fail.
Every company is unique. Mindless copying of practices wouldn't work.
Not all team members will be happy with the suggested changes. That's why persuasion skills become essential.
Any process becomes outdated over time and requires an update. In fast-growing startups, this period could be short. The most important thing is to spot what needs to be changed now and what can wait.
