My name is Ilya, I’m a product designer and manager, currently leading the Product and Visual Design team at Juro
I started about 10 years ago as a visual designer, then I switched over to the role of UX researcher. After that I became a digital product designer, and now I’m a design manager.
I’m obsessed with how things work, always trying to dig deeper into why companies and people grow and improve, why some of them become successful, while some of them don’t.
The Super Power
At Juro, we treat communication among teams as a major thing.
We’ve built a couple of processes that enable all the people at the company to be involved in product-related discussions.
For instance, we never push forward a product-related task until we’re sure that we’ve shared it with the whole company and gathered feedback and thoughts from our colleagues.
Moreover, our teams have weekly alignment meetings. Learning what our colleagues from Customer Success or Sales have heard from customers and prospects is really valuable to us. And, vice versa, we share with them insights that we have on our side.
We use default tools for communication — Slack, Zoom, Google Meet, Notion. Additionally, our rule is that every new Juror from London should have a trip to Riga (and vice versa) to meet the rest of the team in person (before COVID times). This works way better than Zoom calls or anything else.
The Product Development Process
We’ve been building a process that allows us to move fast and, at the same time, make sure that we address the real pain points of our customers with our product.
In a nutshell, our product development process looks like this:
Investigation → Internal Communication → Prototyping → Prototype Validation → Development → Testing → Result-Tracking
How are designers involved in this process?
A major part of the product development process is our design process, so it’s present throughout the entire thing.
We have a single source of truth where all the company collects their insights and everything we know and hear from customers.
Every week, our designers analyse this source and look for general patterns in our users' behaviour and their pain points. When it’s done, we update our CJMs according to what we’ve discovered. These CJMs and those insights allow us to see what we can improve in the product.
This work is an entry point for the rest of the process, starting with the investigations. Additionally, the whole company (especially Customer Success and Product teams) is involved in the ‘Validation’ and ’Testing’ stages. That allows us to get feedback and criticism from every person on every team.
Stages like ‘Prototyping’ and ‘Development’ are mostly for the Product team; we usually complete them internally.
- The goal: to be sure we are doing the right thing.
- Who: the product designer.
- Result: a Notion page.
Generally, we use our own Notion template for investigations to collect all the info in the right way. Previously we used Miro, but now we have all the CJMs created in Productboard. This is not the best tool for creating and maintaining CJMs, but it allows us to link insights that we get from the whole company to the specific stages of the CJMs.
That means that, when we start an investigation stage, we can find the proper place in the CJMs and all the insights related to the problem in a matter of seconds.
This stage is 100% thinking and writing, so here we describe how we understand the problem, all the user patterns that we see, and all the problem-related ‘tasks’ that our users want to complete.
Additionally, we can book calls with customers who gave us the insights to discuss the problem a bit deeper with them.
- The goal: to align on what we know about the problem with the rest of the company.
- Who: all the company.
- Result: reviewed investigation.
If the previous stage is about writing, this one is about talking. To be precise, this stage consists of several sub-stages, but the general idea is simple: we share the investigation. We send the doc right to the Slack chat and ask to review it. The main contributors here are Customer Success and Sales teams. We ask them to read it over and say what they think we might have missed. They either comment right in the doc or we book a Zoom call with them and discuss the investigation in person.
- The goal: to make sure we do things right.
- Who: the product designer.
- Result: a clickable prototype.
That’s a simple one. Once we have a reviewed investigation, we treat it as a base for drawing things in Figma. A product designer creates a prototype and aligns it with all the scenarios that they have in the investigation document.
- The goal: to test the prototype.
- Who: the whole company.
- Result: a validated prototype.
This is an interesting one. We’ve noticed that it’s hard to test conceptual ideas via user interviews if you’re a SaaS company trying to reinvent something really conservative. People often get used to old-school solutions (even if they don’t like them) and bring their expectations to the interviews.
That’s why we’re aimed at developing basic solutions fast and testing them in real life. That works much better for us.
Nevertheless, we test prototypes internally to make sure we don’t miss anything important. Usually, a product designer records a short explanation video using Loom and shares it along with the clickable prototype in the Slack chat. The whole company gives us feedback. Usually, we repeat this stage a couple of times.
5. Development and Testing
- The goal: to build a solution.
- Who: the product team, the whole company.
- Result: a finished solution.
I think these stages deserve separate interviews. :) But in short: we build the solution, then we test it and make it stable. Then we release it.
6. Tracking of Results
- The goal: to make sure the solution works.
- Who: Product and CS teams.
- Result: an understanding of what to improve.
In the Investigation stage, we decide what metrics we’re going to track to make sure the future solution works. That allows us to carry this understanding throughout the process and implement into the app the necessary events to track. We use Amplitude for qualitative analytics and Hotjar to review user sessions in Juro. Sometimes, if we see that our solutions have issues, we rapidly deliver improvements and continue the tracking.
Design Tool Stack
As I mentioned before, product designers at Juro basically think, write, and draw. That's simple:
- Think — we use Productboard to collect our product insights, analyse them, and create CJMs related to these insights.
- Write — we use Notion to keep and share our investigations.
- Draw — we use Figma.
The Juro Design System
The Juro design system has 3 main parts: its consistency, its principles, and its relevance.
It’s all about the UI design library we keep in Figma. We use an approach very well-known among designers: we keep our stuff divided into 3 groups (I’d say it's a simplified Atomic design system): atoms, molecules, and organisms.
Basically, on the lowest level, we have product colours, typography, and icons. In the second layer, we have simple UI elements (buttons, inputs, snackbars etc.). And in the upper layer, we have a bit more complex constructions that may contain 2 or more elements from the 2nd layer. And so on.
I’d say this part is way more important for us than the previous one. We have a couple of principles that we try not to break when designing the product. I think the most interesting one is ‘Be Unbreakable’.
Internally we often say that Juro is built for exploration. We need to design interfaces that allow our users to stay curious and explore the app but don’t punish them if they make mistakes. I'd say this is my personal top principle, which is always super important, but difficult to maintain.
As designers, we share knowledge with each other. We have daily design stand-ups where we briefly describe the problems that we’re solving as designers and ask for opinions and help from our colleagues. This helps us to be consistently updated on what is going on in the design team and discuss the best way we can update the design system proactively.
We created our design principles to support and maintain the whole product development process. When we began rethinking Juro’s design a couple of years ago, we decided on how we want to be treated by our users.
- We wanted to be sure that we always understand real users' problems.
- We wanted to keep the basic Juro flows super straightforward. Forever.
- We wanted to make sure that every Juro interface could be reached from mobile browsers, even if it has super complicated functionality.
That’s why we created these principles:
- Put the problem first.
- Focus on consistency.
- Be Lucid.
- Be Unbreakable.
- The basic flow is intuitive, not learned.
- Be Modular.
- Be Mobile-ready.
We treat them not as quantitative metrics, but as a part of our design culture. When a prototype is ready, we use these principles as its validation layer. Basically, a product designer asks themselves a number of questions to make sure the prototype meets all the requirements. I've already mentioned the ‘Be Unbreakable’ principle, so the questions for this one look like that:
We can never say ’this is bullshit’ when a prototype is ready. Because, if you, as a product designer, go through investigations, detect the users' problems right, communicate and validate your solutions and finally follow the principles, you get at least an okay result. And in further iterations you get a good result.
How to Build a Unicorn
I think this is the question that has no right answer.
And, after almost 3 years at Juro and a couple of startups I went through, I can honestly say ‘I’m not 100% sure what the answer is.’
But I can share my observations.
I often see that the entire lifespan of an average company consists of 2 major parts (very roughly):
Finding the Way
Some of us call it ‘Product-market fit’, some of us say ‘Know the pain-points’ or even ‘Do the right things’. All of them are legit, and, in a nutshell, they mean ‘Know exactly what value you give to your users.’
I would say this is a super uncertain part of a startup’s life because it's all about having a hypothesis and having the need to prove it.
Growth and Execution
Some lucky companies find their way and get a clear understanding of why their users use their solutions and love them. But this is not the end of the story; rather, it’s just the very beginning.
Because, after you found your way, you should find a proper direction towards getting a compounding and sustainable growth. And I’m not only talking about marketing or stuff like that.
There are a lot of questions these guys try to answer:
- If I get new users today, will this trend keep up tomorrow?
- We are valuable for users today, but how to keep this value tomorrow?
- They’re using my product today, but what happens if they come across a competitor’s product tomorrow?
And many more questions.
Both milestones will very likely kill you as a company. This is the fact, yes.
If you’re at the first stage, you don’t have much time to test and iterate your hypothesis and find your way, even if you've got your first check from investors (which is not a common situation these days).
If you’re at the second stage, you don’t have much time to find a way to execute with high quality and also grow. Are your developers experienced enough and know how to scale your solutions? Are your designers talented enough not to break user experience? This is the stage where it’s so important to have well-built processes, principles, and methods, to maintain the quality of the product.
I think it’s not that often that a startup has both:
- A strong hypothesis which converts to a strong understanding of users;
- Strong executors.
I would say, this is one of the reasons why companies don’t become very successful or even die.
The Impact of UX Design
From where I stand, the second stage (‘Growth/Execution’) requires a lot more UX design work and expertise than the ‘Find your way’ stage. I lean towards simplifying things, so let’s compare a few examples to discuss what I mean.
If we’re talking about products like Figma, I think they've never been through the ‘Find your way’ stage fully. Before Figma appeared, a couple of companies had proven a hypothesis that product designers have slightly different needs than others. And it was more or less clear that they needed to work together and keep their stuff at one single place.
That’s why Figma skipped the first stage and started right from the ‘Execution/Growth’ stage and did a stellar job there with super-talented designers and developers.
As an opposing example, I’d like to mention a product named Roamresearch. I use it daily and find the core idea very strong. Potentially, they will attract a lot of users in the future.
They spent some time at a stage where they were developing solutions and trying to find their way. And finally, that happened half a year ago or so, with no designers or strong UX decisions.
As they’re at the second stage now, I think they will start paying more attention to the execution — design, the app's stability, scale. Because if they don’t, they risk losing momentum. And then they’ll be beaten by a company which can skip the first stage because their idea is proven so they can start right from the ‘Execution’ stage.
Advice for Juniors
I found out that everything that works for me as a human being in terms of learning and improving my skills is very likely to work for me as a designer or manager.
So let's start from personal development and this will lead us to designers and their professional development.
My main principle is very simple:
I need to have a subject to which I can apply my new knowledge
Sometimes it happens that I read a book or an article and make some conclusions which might be completely different from the conclusions I'll make one year later if I read the same article.
Meaning your experience today changes everything you will be learning in the future.
Once we start gaining experience, a lot of questions will arise → and once they arise, we'll start searching for answers → and once we start searching for answers, then all the resources which we can find are supposed to be good for us.
So, as practitioners, we make requests to ourselves first, and after that we search for the knowledge that can fulfil these requests.
How to Measure Design?
I never think of designers as ‘good’ ones and ‘bad’ ones.
I can see experienced designers who continue to learn and inexperienced ones who have not learned much yet — or even stopped learning.
As designers, we all make mistakes. And the biggest question is what we should do with them. Do we treat them as something that needs to be investigated and learned from? Or do we leave them ‘as is’ and make the same mistakes in the future?
By the way, if you are reading this and you’re an experienced designer who loves learning and iterating — Juro is hiring and waiting for you.
One topic I’ve been into recently is how people interact with each other.
I see that, for instance, three people who work together and communicate properly are usually way stronger than a team of three which works under the direction or leadership of one person.
And, to me, the former looks more appealing
What happens if someone generates an idea and gives it to me, and I am, in turn, able to work with this idea — even if I don’t like it in the first place?
I try to understand the underlying cause of the idea, understand how it surfaced in the mind of my interlocutor, and then give it back improved, but never declined. More specifically, it’s all about the difference between ‘yes, but...’ and ‘yes, and...’
We communicate a lot with Pavel Kovalevich, Co-founder of Juro, to find a way to bring it to our team as part of the culture.
We started small by asking ourselves how we can become better at conveying meaning. People generally hate meetings and most of us hate wasting time! This means that one very effective way is being both direct and respectful at the same time.
Getting better at communication is an endless journey, and there’s no single destination as communication depends a lot on culture, personal skills, and established rules. It is also about yourself: understanding your own motivation and triggers is a huge helper. But it doesn’t stop there as having high levels of empathy and caring about the people you communicate with makes a difference that can’t be underestimated.
Imagine that three people work together in the following way:
- the first one generates ideas;
- the second one gets them and improves upon them; before they pass it on to
- the third one, who does the same thing before the first one gets it back
How does this work?
The three people are a solid, maybe slightly rigid, system. So if another member comes to the team, they not only become an additional member who adds 25-30% of productivity, but also a multiplier who improves the system significantly.
Meaning you can build a better team that are enjoying what they do because they achieve better results, create better ideas and deliver better solutions without the necessity to expand the team significantly.
I think I've got some ideas from the popular book Flow (how to bring yourself to a state where you’re very productive and enjoy the process), and some practical bits of advice I found here: How to have impossible conversation.
But, anyway, this is a long way to go, so if some of you, our readers, have experience in building this kind of culture, please contact me on Fb or LI, I’m super interested in hearing from you.
I remember when I switched from Sketch to Figma three years ago or so, the main reason was not only the features for team collaboration, but features related to access to designs.
If I recall correctly, back then the most popular flow for designers was like this:
- create using Sketch;
- present using InVision;
- keep versions using Dropbox or Abstract;
- share them with developers using Zeplin.
But the ’team work’ itself was never the top-case for me personally or for teams I was working in. Even now at Juro we rarely work together on the same prototype at the same time, but we massively use the Figma features letting us keep and update the design system in one place, share the prototypes with just one click, control prototype versions, and so on.
Design tools going to the Cloud is a natural way of developing and supporting apps.
Do you think it is harder nowadays to be a solo designer?
I think it depends on the role of designers.
If we’re talking about freelance product designers, I tried to hire one a couple of times to support the product development process, and every time that was a bit difficult for both us and the designer. We noticed that we need around 2 or 3 months to onboard a product designer properly, to make sure they follow our principles and processes and understand what we mean by ‘achieving a good result.’
So, in this case, it’s almost impossible for freelance designers to work with us. But at the same time I can see that visual and marketing designers, as well as illustrators, can be onboarded a bit easier and show results faster. The reason is that the projects that need to be covered by visual designers are usually smaller and their shapes are more clear for the people who are involved.