The process of creating a new app is not something to be improvised. In 2019, users worldwide downloaded over 200 billion apps. And those users are just as quick to delete an app as they are to download it, if there’s a single glitch or the design feels a little off.
At STRV, we’ve split our app development process into four phases: Discovery, Design, Development and Insights. This allows us to address every issue and to incorporate every lesson learned in our 16 years of experience. As with anything of value, our process is always a work in progress. But the foundation of it is steady and has proven to be one of our biggest strengths.
With the creation of any product from idea to market, we start with the Discovery Phase. This is the time to go into detail with the client, figuring out what we’ll be building, for whom and why. We explain details of this phase in our Making an App, Phase 1: Discovery article.
Following Discovery is the Design Phase, without which the product and any developer working on it can’t move forward. And which is much more complex to navigate without having previously invested sufficient time into the Discovery Phase.
To get expert insight into how the Design Phase is structured and why, we decided to speak with STRV’s Design Team Lead, Ales Nesetril, and Product Manager Katerina Douskova.
Ales Nesetril, Design Team Lead
Before we get into the workings of the Design Phase process — Ales, as the Design Team Lead who has been with STRV for over five years, can you tell us how we actually reached this point of having a set system in place?
Ales: There’s always the path of trial and error. Being in the business for years, we learned from mistakes and had the time to establish key points of what works well for us and our clients. Right now, we stand on solid ground of a proven approach and time-tested processes, and we can continue to build on top of this even more.
To me, keeping our system strong is not an autocratic thing. It was created by everyone coming together, establishing what’s worked for them and their projects over the years and giving this process bulletproof structure. We made an agreement of staying consistent, sticking to certain stages, using the same tools and processes. But certain details will continue to evolve, just as the business we are in and the technology we use evolves. We tweak things based on what we’ve learned on recent projects. Because if you think there’s no longer room for improvement, you’re just not looking hard enough.
That’s actually how the whole research phase—the Discovery Phase—came into existence. We began seeing great value in learning about the client, the users and all requirements before starting design, and we pinpointed that certain failures were due to us not having the full scope of information. We were investing time, but not at this scale—which meant we were just scratching the surface of what we could know if we had a system in place. So we implemented Discovery as a whole new stage, a sophisticated approach to research that connects the design team with the delivery team.
Katerina, with rich experience taking products through the Discovery Phase and into Design, can you provide some insight as to how that transition works?
Katerina: Assuming a client went through Discovery with us, that phase ends with a product manager and designer who have worked together with the client for quite some time and now understand what it is they’re building. That’s all incorporated in the wireframes (a sort of skeleton format that focuses on functionality and is a rough outline of future designs) that have been prepared in Phase 1, and that have gotten the OK from everyone involved—on the client’s side, and our own.
We enter the Design Phase knowing what we’re building, and we start working on the how. The product manager’s main focus is to make sure nothing is forgotten, no feature is left out. And together with the designer, we discuss which development issues may come up with this specific product; maybe we might have to spend a bit more time on UI, for example. Everything is analyzed from all sides so that once the designer gets to work, he/she is absolutely clear on what needs to be done, and how to transform the wireframes into a real product.
Can you quickly explain exactly what these wireframes are, and how they’re different from the actual designs?
Katerina: Working with wireframes is the time when we edit features and ensure we have all key components. It’s not about the colors and icons and about how pretty it is. It’s about functionality and layout. The thing is, our wireframes are very high-fidelity and actually look like some companies’ final designs, so it can be confusing. Clients sometimes can’t help but focus on the look, and we have to guide them towards focusing on the functionality and general structure. But on the other hand, they’re that much more blown away when they see the actual designs and the entire visual aspect coming together.
Then there are clients who really like the look of the wireframes. That’s when we kind of just think, “Man, you haven’t seen anything yet!”
From left: Product Manager Katerina Douskova, Design Team Lead Ales Nesetril and Senior Copywriter Linda Krestanova, taking a mental break mid-interview. Hope that's Kate's "good news" face.
Once design commences, how do you work on setting up the communication between designer and client to ensure STRV’s high collaboration standards are met?
Ales: It really depends on the project and how involved the client prefers to be. It’s usually up to the designer and client to decide how often they will sync. Does the client prefer seeing every small change, or just have a call once a week? We adapt to their preferences. But what we always do are daily stand-ups on Slack, where the designer writes down what he/she worked on and what’s next on the agenda.
From a designer’s point of view, we really enjoy working with clients directly. It allows us to make sure both sides are well-informed, which means we’re making the right decisions on the go.
STRV’s ability to remain organized and transparent both internally and with clients is often highlighted in our client reviews. What tend to be the most highly regarded aspects of the Design Process?
Ales: There are three main approaches our team has that allow for great internal collaboration. The first is that, on an individual level, we have “buddies”. This means that every designer working on a project has a fellow designer to talk to at all times. They review the work together, can talk about it on the go pretty much every day and they kind of supervise one another.
The second is that we have show and tell sessions that are basically design critiques and feedback. They happen every two weeks. A group of designers sits down and talks about a specific screen or flow that someone is currently working on, and it’s great for the designer to get more context, to see it from different angles and to come to a decision if there were any uncertainties.
The third is having bigger group updates as a team, which means all designers are present. We do this every two or three months, and we discuss if there are things that need to be changed. For example, right now we’re implementing Dark Mode into our work, which impacts STRV’s Design Handbook. We’re tackling how to best talk about it with our clients, how it will affect estimates and how to approach the work in general. Since some designers have already had to approach this themselves, they’ve seen it in practice and, if what they’ve done works, it can be implemented for everyone.
Dark Mode UI concept by STRV
How do you work on updating the Design Phase if there’s a need to adjust to a change in the industry?
Ales: The process is absolutely collaborative. It’s not only me trying to change things; as my team experiences different situations during projects, we tend to either refresh our process or at least take a close look at it. We discuss what we can change, and this means we naturally move forward and don’t get stuck with something that is outdated. This is important because clients are always facing new challenges due to new technologies coming out or being planned, and we want to make sure we remain aware and educated so we can immediately or eventually deal with anything. That’s a big part of finding solutions.
From both of your perspectives, what are some common challenges of this phase — in terms of client communication and the work itself — and what are your roles in tackling those challenges?
Katerina: It can happen that there are too many cooks in the kitchen, which leads to endless rounds of revisions. One person wants blue, the other pink, another wants to tweak minor details. That’s when the product manager has to step in and limit the number of possible revisions. Otherwise, the timeline is changing, which affects the cost and pushes the release date further away.
It’s also when the product manager reminds the client that our designers are experts in their field. They understand which styles and aspects work well together. And even still, the designers’ decisions are never unyielding; we provide clients with options to choose from. This can actually be problematic as well, if the client attempts to combine parts of one option with another. A professional designer and developer sees why those parts simply won’t work together, and it comes down to communicating this with the client and ensuring there’s an understanding. Or, if that fails, we turn to user testing of the designs and collect feedback. Once there’s data backing up our experts’ decisions, it’s easier to agree.
In the rare cases that the client does not back down, yet we know the suggested changes break all UX/UI rules, we look at whether or not this potential change adds value to the product and the end user. Because if it doesn’t, it’s wasting precious resources for no reward.
Ales: From my experience, when clients feel doubtful about something, they’re usually looking for trust. They aren’t sure how to confirm that the designer has made the right decision, and sometimes call for a “supervisor” to explain. This is where our collective intelligence—like the buddy program and our regular meetings—comes into play. We’re able to reassure them that at least one other person on the design team has seen the work, and most likely we’ve all discussed the product together. The design is not just a result of one designer’s personal preference. Although one person is officially assigned to the project, that designer takes multiple suggestions into consideration when making that final decision, making the process a true team effort.
Additionally, we always have the option of testing ideas with the product’s target audience, which we utilize on the go as needed, and I’m personally constantly overseeing the work of the entire team.
As someone who has worked on many notable projects inside and outside of STRV, what do you feel makes STRV designs worthy of the esteem they have received?
Ales: I think it's important to mention that we’re able to make both the UI and UX parts of the project work together very well. Unlike other companies that often prefer focusing solely on one of those aspects, we're able to take on both the functionality and aesthetic feeling of product design, as both are a part of our team’s skillset. In the end, it's all a part of one experience for the user, and understanding the ins and outs of both the technical and the visual—which are, in a way, different disciplines—means we can make sure the product not only works properly but is engaging.
The market is so saturated that if you really want to stand out, you need to invest more and take a bit longer to be different, rather than just doing something your competition has already done. Yes, you can have a successful launch without going the extra mile. But to stand out, it’s important to consider not just the structure, but the overall look and feel. Investing more into visuals means investing in smaller details pleasing to the eye, and investing into the logical parts means investing in clever touches that make the app more user-friendly. If you give great designers enough space to come up with a variety of ideas, the product will outlast its competition.
OPKIX screens, designed by STRV
If given this freedom to explore any and all options, how does an STRV designer utilize that to maximum effect?
Ales: It can be hard to imagine just how far an expert designer can push a product if given the chance to go creatively wild and to bring innovative solutions to the challenge at hand. Given the opportunity, we can really take things to the next level. A big part of doing that is by incorporating the conceptual phase in the design process.
The conceptual phase usually takes a few days, and it puts zero restrictions on where the design can go. It allows designers to explore different ways of approaching the project, in terms of both the technical and the visual side. They’re able to play around with different ideas, creating a brave vision that doesn’t take the initial briefing’s guidelines into strict account (while still keeping them in mind). This is usually the time we get to blow our clients away and inspire ideas from all sides. It’s a lot of fun for designers, because they’re basically put in a position where they can come up with a new direction for the product, one in which they really believe, and they get a chance to present it, back it up and sell it to the entire team.
Can you provide an example of an STRV client who gave our designers the chance to play and ended up with an exceptional result?
Ales: OPKIX is a good example. Because OPKIX sells an interesting product—a compact handsfree camera that can be attached to almost anything—the design was built around the idea of having the camera and its content in full focus. The UI is designed to not come into conflict with the product brand, so it allows users to play with the videos. It is a minimalistic look that takes time to design, but it fits the brand of the actual product very well.
If a client chooses to utilize non-STRV developers following the Design Phase, does it affect our work in this phase?
Katerina: Not at all. Just like at the end of Discovery, Design also ends with a full kit of information. From the design side, this information includes wireframes, the full UI, the interactive prototype and a detailed Style Guide. From the product side, we have full product specifications that describe every single feature, the breakdown, overview, user story... the whole thing mapped out. So if someone knows nothing about the product, they can open this document, understand it top to bottom and start developing. Clients almost always choose to continue with us to the next phase. But in the rare cases that they do not, a non-STRV developer can pick up where our designers left off without issues.
Are STRV developers a part of the Design Phase in any way?
Katerina: Our developers are always available for input, which is a huge benefit. Because sometimes, we do need them to jump in. For example, a designer might have a great idea and, although our designers’ experience usually means they understand what a design requires from development, there are times when an idea is very new and pushes the envelope. Those ideas are what elevate our designs, but they require that we ask developers how long it will take to incorporate—because the timing affects planning and cost.
And of course, as we move through the Design Phase, we’re speaking with developers to find the best fit to bring in for the next phase - Development. Look out for that article, coming soon!
Huge thanks to Ales and Katerina for providing their input! Still have unanswered questions, or want to discuss partnering up with us?