Our UX design process explained. How to design engaging software products.

Making engaging software products isn’t easy, but with our 13+ years of experience, we’ve learned how to put our UX design skills to good use. So here’s how we do that.

Great apps aren’t built overnight. To bring an app with great UX to life, it takes a lot of research, meetings, brainstorming, trial and error, and a constant feed of questions towards the app owners. 

Since we began app development in 2010, we’ve learned so much that we’ve successfully streamlined our UX design process. So much so that we’ve come up with our own design framework, called UFOs. This acronym refers to a series of steps we follow when building an app: Understanding, Foundation, Original Design and Stress Testing. 

First we understand what your business does, and thus we figure out what the app should do. Then we work figuring out the app flows and visual direction (overall style, colors, fonts). After that, we jump straight into designing the app, and at last, we test it to make sure it fulfills the goals it’s supposed to. Read more about UFOs in this series of articles.

When it comes to app building, our overall strategy is design-driven development: this approach ensures that an app’s look and feel is 100% clear before getting into code. This saves development time and makes app building more efficient - no going in blind, no design work done by non-designers.

So in this article, we’re going to talk about what exactly goes into our UX design process, how we get started, how we make it work, and how we bring successful products to life.

Step 1. We become familiar with your industry and app concept

We can’t build an app without key information. When we begin a new design project, we always start with a kickoff meeting with the client and their team. We ask them about their business, their industry, their app concept or current app (if they have one) and what they’re looking for. We keep it as a conversation rather than a Q&A-type of meeting.

The first and most important part of this is understanding the client team’s industry and business model. We usually let them present and talk about their business as they know it, and at the end we ask as many questions as we can. We’ve worked with some highly complex industries over time, so we’re not new to learning about activities we hadn’t heard of before. But it’s crucial that clients take the time to explain everything until we’re sure we understand. 

For those who’ve built an app already

To help us get familiar with their concept, we usually ask these clients to give us a walkthrough of their existing app. Every step of the way, we’ll ask them a lot of why’s: why do you complete actions this way? Why this way and not [something that seems more efficient to us]? Or anything else that seems relevant. The idea here is leaving no stone unturned.

As we look through the client’s existing app, we often ask them to use it as they would on a regular basis. This is a great way to directly pin-point what’s not working well in their app. Oftentimes, we’d hear them directly say what they have trouble with when using their app, or what users have complained about. Stuff like “This never works, but we found a way around it”, or “We get customer service complaints about this often” helps us get a clear idea of what we can improve.

This is also where we’d discuss customer complaints: if the app is customer-facing, the client team might not always know exactly what the users don’t like about it. We’d ask for any customer reviews or customer service requests so we can see exactly what users are having trouble with. This is a great way to figure out new user flows - reviews not only pinpoint bugs but also issues with navigation, lack of contextual help, annoying features or confusing flows.

For those who haven’t

When it comes to new businesses who want to work with us to create an app from scratch, after we get a good understanding of the business concept and what the app is supposed to do, we focus on the actual users. With no other starting point, this is the best way to figure out the app’s user flows - all we have to do is figure out how real users could navigate the app to fulfill their goals. 

Sometimes, the business owners themselves (and their team) will be the users - in the case of internal business tools. In which case, we expand on our conversation about how they’d use their app in their day-to-day work. This will help us figure out key user flows, as they’ll point out what kind of goals they want to achieve through their app. In some cases, these teams are already using tools to conduct their business (like Excel spreadsheets, for instance), so we’d ask for access to some examples so we can see how we can improve their current workflow.

When it comes to users who don’t belong to the client’s team, in other words, customers, the process is a bit more complex: the clients, knowing their industry, should help point us to where we can find potential customers to interview. If not, we look through industry-specific forums or subreddits.

Once we’ve gathered a few potential users, we interview them to try to figure out how they would use the client’s app. We know they’re trying to fulfill specific goals that the client’s app is targeted towards, so what we need to find out is specifically how they would use the app to fulfill said goals. Here are a few questions we ask:

1. What kind of goals do you want to achieve through this app and why? - Before we find out how they want to fulfill their goals, it’s important to understand what they are in the first place. Knowing the Why can give a lot of useful insights. Let’s say you’re creating a dieting app and you’re interviewing people who want to track their diets. Ask them why they want to do that - maybe they’re trying to eat healthier. Knowing this makes us think that adding recipe recommendations or a section for advice from other users can be useful user flows.

2. How do you fulfill these goals at the moment? Maybe they’re using an existing app but it doesn’t provide everything they need. Maybe they’re using an analog system. Continuing on with the diet app example, maybe the potential users are currently tracking their meals in their built-in Notes app. Or they see recipes on the internet and they save screenshots of them, but they forget about them as they’re not in the same place as their tracked meals. When you ask potential users how they currently fulfill these goals, you discover issues they’re facing. And thus, you can add useful flows to the client’s app.

3. What is your biggest challenge when trying to fulfill these goals? This is a great way to figure out what’s missing in the app they're currently using. If they have their own analog system, this will highlight entire user flows we can add to the app.

Step 2. We gather all info & brainstorm

Once we’ve talked to the client’s team and/or to potential users, we gather everything we found out and we get to brainstorming. There are clear goals the app should fulfill, so what needs to be figured out at this point is exactly how.

We put ourselves in the user’s shoes and picture how they’d use the app step by step, focusing on their end goal. Once we figure out what steps they’d go through, we think about how to point them to each step. In an onboarding process, for instance, we can add a progress bar at the top of the screen to show what step they’re currently on and what comes next. Or we’d app tips to their dashboard with information on what they should do next. 

The key here is figuring out what kind of information is essential to give to the users and how to provide it without cluttering pages. So that’s tooltips, pop-up tutorials, or providing quick walkthrough videos. The best UX is the one that aids users, not confuses them. We like to take the time to figure out what kind of information will help users best, and where to provide it. After all, not all users will know their way around an app right away.

In a lot of apps, users can go on a variety of different journeys based on their selections. And having this variety of actions can propel users into different user flows. So a good way to keep track of everything is physically mapping it out and creating diagrams.

Source

What we like to do is jumping straight into Figma and playing around with low fidelity wireframes. In other words, we create a bunch of boxes and label them with actions that can be done in the app, then we try to put them together in a logical way. Seeing all the possible user actions in front of our eyes makes it easier to connect them and to figure out what user flows can complete those actions.

Going analog with this can also be helpful. Writing user goals down on post-its and physically connecting them together makes this process a lot more visual. Bonus points when using a whiteboard and markers.

In our case, we like to collaborate and brainstorm together. Discussing ideas, research and insights from clients and users helps us come up with user flows quicker. Everyone understands information their own way, and putting all of those ideas together can lead to some great features to the app we’re working on. Plus, we get to peer-test a lot of ideas before we spend hours and hours turning them into a design.

Step 3. Bringing it to life

In our own process, once we’ve figured out what the app should do and what are the key user flows, we get straight to designing. Before we begin, we usually ask for a few things from the client’s team:

• A visual branding guide, if they have one. A lot of established businesses have a set visual identity. That is, specific brand colors, fonts, symbols, icons, illustrations, and of course, a logo. If the client already has a visual identity, we like to stick to that in the app design (unless they want to keep them separate). If they don’t have one, we’ll ask if they have any color or font preferences. If they don’t, we’ll come up with something that suits their business & app concept.
• Any pre-existing design files. With pre-existing apps, it’s best we have access to their design files. This will help us cover all possible flows, stick to the client’s visual branding, and find solutions to the app’s current issues. This is even more important if we’re building onto an existing app and just changing (or updating) user flows but not actual designs. If we don’t get access to pre-existing design files, we’ll spend extra time recreating it from scratch - which is not exactly ideal.
• Access to a current app (if they have one). If we’re adding to or upgrading flows for an existing app, it’s of course very important that we have access to it in the first place. This will allow us to experience the app as if we’re real users and to cover all possible user flows. If the client team uses something other than an original app for their business, we’d need access to that as well. Most commonly, a lot of businesses use Excel documents - having a look at how the client uses these to conduct their business will help us figure out how to transport all of those features into an original app. Why? Because we’ll be able to directly see how they use these documents and what for. If it’s for complex data entry, then we’ll know we need to create forms sorted into tabs for easier navigation.

Once we have all of these things and all the information we need, we jump into Figma to design the app. Usually, we start off by mapping out all the visual elements - colors, typography, icons, and shadows. Setting all of these up in Figma makes the design scalable long term and it also makes it easier to update visual elements without having to go through entire pages and changing everything one by one.

This is based on Figma’s Styles system, where all colors, typography settings and shadows can be set as styles for a specific design document. These styles will then be applied to elements across the design. If the root styles are changed, they’ll automatically update throughout the design file (unless we change style names as well).

Once we’ve set up all the styles and imported a set of icons, we get to creating each screen. Since we’ve established a series of user flows, we go in order of said flows and we organize the screens as such. This allows us to easily follow the flow through the flows once the screens are complete, and find anything that’s missing.

Step 4. Improving it through feedback and testing

Once an initial version of the design is complete, we usually schedule a presentation meeting with the clients to give them a walkthrough of the new user flows. This way, they get to give us feedback on the spot and we also get to brainstorm ideas together. Having something clear and visual in front of us makes it so much easier to come up with new ideas.

Based on the client’s feedback, we usually go back in and update the design, if needed. In this stage, communication is key: as a client, be clear about what you want and what you like & don’t like. This will help finish the design quicker and move the project along. Otherwise, we risk having an endless back and forth for minimal design changes. Alternatively, we can hold meetings where we discuss feedback and make direct changes to the design until we’re all absolutely on the same page.

Once the design is finalized, we can go in 2 directions: we can code it right away, or we can test the new flows beforehand. We usually head into coding, and then manual testing - this is the best way to act like real users and test the new user flows, as there’s only so much you can imagine via static designs. If the client’s team will be the real users, they’ll get to test it as well. With manual testing, we can figure out edge cases and additional user flows to cover.

Alternatively, the new UX can be tested with potential users, just like we evaluated their opinions at the beginning of this process. This can be done through A/B testing, where we show the participants the initial UX and the new one we proposed. They’ll be asked to compare the two and point out which one would work better for their needs. This ensures that the new flows fulfill their needs and cover the issues we worked to solve.

Directly launching an MVP of the app is also a great way to test out new UX. Through an MVP, you get to evaluate how well your app works for your key audience, and what you can do to improve it further. Invite your users to leave feedback and be open to their opinions.

And there you have it, that’s a rundown of our own UX design process. Overall, the most important part in creating engaging software products is having a good understanding of the users and their goals - once you have that, you can create a product that truly helps them achieve their goals and which brings your business the conversions you need. After all, it’s called user experience.

Are you in need of new UX design yourself? Contact us and tell us about your business and let’s see what we can create together.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.