Disclaimer: The text mentions products related to nicotine use. We do not encourage you to smoke and remind you that smoking any nicotine products is harmful to your health.
We usually build MVPs from scratch, but sometimes, customers come to us with their own developments. This was the case with SOAK — they came to us with a ready-made design, but the layout was missing important details.
First, we will do a little dive into the customer’s business and their request. This will help you understand everything we will talk about later.
Context: developing an app for e-cigarette sellers
Our task was to create an app for SOAK distributors. They display electronic cigarettes and POD vape devices in their stores and consult customers on models and flavors.
According to the client’s idea, the app should help sellers better understand the world of e-cigarettes — they complete tasks, get prizes for correct answers, and thus, increase their knowledge about the product.
App with gamification elements: sellers take a quiz about e-cigarettes and get prizes for correct answers
The app was designed by a SOAK in-house designer. They just asked us to help them with the development. But when we immersed ourselves in the task, we realized the layouts needed refinement, otherwise there might be difficulties in the development stage.
By the way, not long ago we told you about the development of a PWA application for Plonq, an e-cigarette manufacturer.
In this project, we helped the client’s in-house team solve all the development challenges and create an app for people who want to quit smoking. Read how we took on a burning task and literally became the client’s “hands” in this case study.
5 things to consider in design to avoid problems in the development
Here are the things that weren’t originally in the design, but should definitely be included so you don’t get stuck in a round of edits:
-
- UI kit. Without this, developing and adding new scenarios can become a nightmare.
- Store guidelines. App stores won’t let you release apps without “I agree to the privacy policy” buttons and other not-so-obvious little things.
- User journey. Otherwise, a user may end up in a scenario that designers haven’t rendered and get confused.
- UX patterns. These are established user habits, and their violation can discourage users from using the app.
- Small screen adaptation. So that the design does not fall apart on older phones.
Now, we’ll tell you about all of this in order.
1. UI kit
A UI kit is a set of components that make up an interface. It is found in almost every project related to digital products, from international banking apps to local online stores.
The kit contains the app’s visual details. For example, what the buttons look like — their color and outline thickness. It also includes technical parameters for developers: button behavior, color code, and font size.
Elements of the UI kit for SOAK that we helped build
With the UI kit, the interface looks uniform and harmonious. It ensures that the design on different screens is consistent — buttons have the same distance from the text, and logos have the same color.
Without the UI kit, the design feels careless and “cheap.” Also, development becomes more expensive — programmers will have to choose the parameters of design elements themselves to make the application. By the way, we have already described how to build a UI kit from scratch.
When we started working on SOAK design, the application didn’t have a UI kit. This made the product look heterogeneous.
For example, the same headings had different font sizes on various screens, and similar icons had different outline thicknesses. It was eye-catching and looked careless.
Compare: on the left is the screen created without the UI kit, and on the right is the finalized screen with a consistent design.
We helped build a UI kit from elements that the client already had. Without the kit, colors, sizes, and fonts have to be chosen by the developer. This is time-consuming and increases the risk of errors.
With the UI kit, it was easy to develop the application and create new screens as needed. And in the case of SOAK, they needed to be added.
2. User journey — states and screens
At the beginning of every design project, we build the user journey. Business analysts describe in detail what the user can do in the app, where they can go, and what situations they will encounter.
The artifact of this stage is the user story map. Designers take this map, work their magic, and get a screen map, or UX map.
The UX map helps to work out the user’s steps in the application. This way, you can immediately see what screens are needed.
The SOAK app design had problems with the user journey. Here are the things that were missing — without them, users could easily get lost in the product:
-
- Linking screens
- Edge case screens
- The button and screen states
Let’s take a closer look at them.
Linking screens. They show that the app is loading, money has been sent to the card, and task points have been added to the account.
Without them, the user feels like the app is frozen and not working. Distributors can write to support more often, which results in additional load on the client resources and wasted time.
Added a success screen. If a user completes a task and doesn’t see this screen, they’ll think the app is glitching.
Another example is when registering, the user has to enter a phone number and confirm it with a code from an SMS — a standard scenario for many applications. However, in the layout for the registration flow, there was no screen with a field to enter the phone number and code. We added it.
Added the missing screen
Edge case screens. These are rare application usage scenarios, but they are important for a comfortable user experience. For example, in the SOAK app, a user had to enter a unique code to confirm the completion of a task. We had to consider that the user might enter incorrect data or try to send the same code repeatedly, and added warnings for different cases. Otherwise, the user would not understand what the problem was and would think that the application was “broken.”
Entering incorrect data in the field — a common edge case that needs to be considered at the design stage
Of course, these situations don’t always happen, but if you don’t consider them, you could lose a user.
Button and screen states. These are the states of elements in different contexts. For example, how buttons react when you hold your finger on them, tap them, or leave them alone. If a button cannot be tapped, it must have a corresponding state. Without it, users will keep tapping the button without understanding what went wrong.
Added different states for buttons: normal state, inactive state, and after a tap
There were no error states in the SOAK design. If a user entered an invalid login or password in a field, the interface would display nothing – but it would not let the user proceed.
Notify the user when something goes wrong
The same applies to points. If a user tried to withdraw money and didn’t have enough points, the interface wouldn’t respond. It felt like the app had frozen. So we added a popup with a warning.
3. UX patterns
When designing apps, our team takes UX patterns into account — behavioral patterns that users follow. For example, the “Law of Proximity” — elements located close to each other are perceived as a group. Or “Miller’s Law” — an average person can hold attention to 7 elements at the same time.
UX patterns make it easier to create an intuitive product. The more familiar scenarios an app has, the easier it is to understand it from scratch.
You can ignore the patterns and start making something of your own. But then, you have to hope that the user will figure it out on their own, or be willing to take the time to understand the product.
There were 3 distortions of UX patterns in the SOAK app:
-
- Headers look like buttons
- Logical errors
- Icon colors don’t match their meanings
On some screens, headers looked like buttons. Users could tap them out of habit – sitting and waiting for a section to open that didn’t exist.
Logical errors. For example, in the tests section, some questions require you to select an answer. The designer made the buttons for these options look like checkboxes instead of radio buttons.
With checkboxes, it seems like you have to select multiple answers when you should just click on one. And it feels like the app is glitching because it won’t let you choose the answer you want.
We got rid of logical errors in the UI. Now, the user looks and immediately understands what to do.
The colors of the icons did not correspond to their functions. For example, if a user answered correctly, the icon would light up red — it seemed like the user had done something wrong.
Fixed inconsistencies in the interface — everything looks logical and clear
We gathered all the problems with patterns, buttons, and screens we found and left them as comments in Figma. This made it easier for the client’s designer to finalize the screens with states and bring the layouts to a unified look.
4. Store guidelines
For stores to approve the app, you need to work out the privacy policy and add the button.
Without the “I agree with the privacy policy” checkbox, you can’t collect data. If it’s not there, stores won’t allow the app to be published.
The original design of SOAK did not consider the privacy policy thing. If you leave it as it is — don’t say anything about it — the app will not pass the stores’ moderation.
Added a data processing consent section. It was not in the client’s design
5. Small screen adaptation
During the design process, we take small screens into account, such as the iPhone SE. For this purpose, we made the buttons and headers a bit smaller, so it would be comfortable to use the app on these devices.
In the SOAK design we received from the client, the buttons were huge. The distance between the text, the borders of the button, and the caption itself was too big.
These buttons didn’t fit on a small screen — they had to be cropped to fit on the page. You could try to leave it as it is, but then, you’d have to scroll through each screen to find the button you wanted — it’s not obvious and inconvenient for the user.
Changed the distance between UI elements and reduced the button size to make everything look normal on all devices
All design finalization and preparation for development took 2 weeks. This is a typical Agile sprint for us. All the time we actively communicated with the client’s in-house designer and together we improved the interface.
Conclusion
It took us two months to design and develop the SOAK app. It was downloaded more than a thousand times on Google Play. The client is satisfied — this product is more about image. And for our help, the guys from the company sent our team e-cigarettes as a gift.
Checklist: what to consider in design before development
We’ve made a Google Doc with checkboxes for you and briefly outlined all the steps. If your in-house designer doesn’t have much UI/UX experience, this checklist will help ensure that the design considers all the points we’ve covered.
Download the checklist from a Google Doc
Or contact us at Purrweb. We can make an MVP from scratch: develop the design, build the app, and release it in the stores.
Fill out the form below to contact us. We will listen carefully to your idea, share our experience, and estimate costs and deadlines.
