“DON’T MAKE ME THINK” MADE ME RETHINK MY FIRST DESIGNED APP

This article was inspired by the “Don’t Make Me Think” book by Steve Krug and AJ&Smart who recommended this book. I’m opening a new series, where after each UX, product design, or other related books, I’m breaking down some of my projects and rethink, criticize or praise them.

Pre story

I’m a mobile developer and I’m new to UX/UI. In 2019 I worked on a fitness app. By the chance, maybe because of my sense of authenticity or simply because no one else wanted to bother with it, I got a task to design the app. It’s embarrassing to tell that back then I thought it won’t be hard, my apologies to all designers out there! It was F hard! First of all, I had no experience, but just a sense, which is a subjective thing. Though, thanks to this opportunity I found my passions and pure interest to design.

Design

I started by reading the specifications and designing a lot of different screens. I thought it was a design creating, but in fact, it was just ideation. I didn’t look at competitive or similar apps, I used old school design patterns, not to mention that I was designing in Androidy style, since I never developed for iOS. There was no user testing involved, except the negotiations with the team and then the customer. This was a challenging task since I also had to develop it and I was always thinking in terms: “how I can do it in code”, this thought helped me not to go too far into fantasies, but same time stopped me from designing some details when I wasn’t sure that I can implement them. This was just the beginning, the real process started when I met the customer. It is funny that at first, my manager told me that I don’t need to meet them, but I remember that later on, I was going to every meeting, cause it helped me to understand their needs and preferences and of course, the product goals.

I did some nice things intuitively, but I spent too much time on unnecessary redesign or refactoring, didn’t pay attention to platform-specific points, I didn’t even know about the importance of accessibility or that there is such a term.

I improved over time and already in the middle of the project development, the process would look something like that:

• read specification
• draw a low-fidelity sketch
• design in Figma
• iterate
• show to the team
• iterate
• show to the customer
• iterate
• implement in code

It doesn’t sound that bad right? We were tight in the schedule and worked in a form of 2 weeks sprints by the end of which the result should be delivered to the customer.

Probably I don’t have to mention that as a beginner, I also went through all these painful discoveries:

• you’re sure your design is awesome, don’t be so sure:)
• it’s hard to find a comprise between the user, customer, and developers
• some things may seem obvious to you when they are unknown to others

I probably knew all of these rules, but when you tackle them in reality it can be a cold shower. It made me think.

Let’s take a look at some examples.

Login forms

I knew that long login forms are what everyone hates. This page had several iterations before a final solution.

Registration with email

The login and sign up processes are identical from the user perspective, the only difference lies in one extra screen that requires the name of the user while registering with email. I suppose, that you imagine how Facebook login works, it’s pretty much automatic, so I won’t go into details. The email login has its peculiarity though, which I honestly took inspiration from a famous food delivery application — Wolt. The key feature is the absence of the password field. I was very happy when created an easy experience for the user.

One of the flaws here is that on Apple device the user is not able to open a mailing app directly from our application. I know I know, the color contrast is just…not there. After reading the book, I also look suspiciously at the text hints within the input text boxes, cause they disappear when the user touches them, which should not happen.

However overall, a year from now, I’m mostly satisfied with these pages, and with no hard feelings (maybe a little) I would let it stay the way it is. If you find more issues with it, I would be interested to hear your opinion.

Splash screen

From my previous knowledge from the Udacity course, I’ve learned that the Splash screen should be showed fast maximum one time if necessary (I don’t me actual instructions pages, it’s a whole different story).

Splash screen

In the Infratrainer, the Splash screen can take up to 10–15 seconds to load, and initially, it was occurring every time the app is opened. All the data was loading on the background while a Splash screen was displayed, and I don’t remember how I missed this part until I realized that the application takes forever to launch. That’s a lesson to think well thoroughly in advance. I had to convince others to change it, but that would require refactoring some of the app architecture and logic, so I worked out the way to perform this heavy load only once when the app is installed and make it shorter when it’s killed. It was a solution, but until now I find this part of the app needs a major fix.

Main page

It’s about lots of brainstorming, compromises, tradeoffs.

Home screen (My Day)

The home screen his page is the most “suffered on” page in the app.

What I’m proud of here is the card design. I still believe that it is quite informative.

Another thing that I like is the info icon in the corner that bears an explanation of the progress bar color indicators.

One of the main problems with this screen that wasn’t solved until now is the amount of information displayed. The customer request was to fit everything on one screen without a need to scroll and we kept on adding and adding stuff. However, I thought that mobile phones tend to be longer and bigger and in general, this should not be a problem. I offered different solutions, but none of them were preferred to the current one, so I hid the issue on some devices by playing with margins, padding, and sizes. In my eyes, this question is left open, so if you have any idea, or if you want to brainstorm a bit, consider it as a puzzle.

One of my radical ideas was to change it in such a way to satisfy the following conditions:

1. preserve one page
2. fit without scrolling the whole screen
3. preserve the functionality

I would break the look of the cards, make it a vertical list instead, and add a function to automatically point to the current time, so the user has to scroll less in general. Limit the page scroll and leave the list scroll only.

That would look something similar to the prototype below (I didn’t make it overly fancy, but in general I would also add a zoom effect for the current time).

Alternative Home screen Figma prototype

And again, the overhead is redesigning and extra coding, along with the 4th condition that I left out intentionally — everyone else from my team and the customer loves the horizontal list and I’m not allowed to touch it:).

Wrap up

Overall, this first experience gave me a lot of knowledge, I could finally stand up and go into the big world, creating something on my own. I love this product, what I invested in it, and what I’ve learned by making it.

As I mentioned above, this app didn’t have any usability testing involved during the process (except for the team), but only after. I know it is a mistake, now I get it and I can assure you that I sensed it back then too. However, I heard nice feedback from people, who were testing afterward, maybe they liked the icons or something:)