“Feels like ages since we last spoke.” 
“Man, you never call.”
“Talk to you same time, next year… Haha, Happy Birthday again!”

I’ve heard, or said, these statements fairly often. Sometimes, they were true. I’m not too good at keeping in with . Sometime in August 2018, I thought I should make an effort to change. So I came up with a system which, essentially, was a bunch of recurring reminders.

A few weeks later, I thought it was going well, but it was, still, a largely manual task and I had to keep making changes and had to keep tracking my calls. I figured that I couldn’t be the only one who didn’t want to suck at keeping in touch.

So, I set out to create a solution. I set out to design an that would set up a randomized schedule to remind the user to call people in their lives. This would ensure that a user keeps in touch with people and is always aware of who they haven’t spoken to in a while.

Before we begin, here’s a peek at the final design.

Here’s the link to the prototype. Refer the tasks in the usability testing section of this if you want to follow the design.

Design Process

Here is the design process that I used in this case study.

For every project I take up, I try to follow a process which is similar to, if not the same as, the one above.

Problem Assumptions

“Users have certain people in their life that they’d like to keep in touch with but don’t, because they don’t remember to do so.”

These assumptions are based on my personal experience. To validate these assumptions, I needed to determine the following.

  1. What counts as keeping in touch for users?
  2. Do users not keep in touch with certain people who they’d like to?
  3. Do users want to get better at keeping in touch?
  4. Do users not keep in touch because they don’t remember?

User Research

I created a survey and sent it out to potential users to assess their current calling habits and ideal calling habits. The population was anyone who owned a phone and spoke to other people on it. So pretty much, everyone.

Survey Results

I used Google Forms and surveyed 22 people, aged 18 to 36, with a 50% gender ratio.

The charts from Google Forms weren’t as helpful for these questions. Some data preparation was needed. I used Microsoft Excel and Alteryx to do so. The exact process of which is outside the scope of this case study.

What counts as keeping in touch?

  • I assumed that voice calls would have a universal acceptance as a means of keeping in touch.
  • Among all the means of keeping in touch, voice calling had the highest average acceptance rate of 64.4% followed by messaging with 57.6%, in-person meeting with 54.5%, and video calling with 39.4%.

Do users not keep in touch with people they’d like to?

  • Although it is nice to see that there is no gap between wanting to talk to friends and family and actually talking to them, I was expecting the numbers to be higher for the other categories of people, such as relatives and colleagues.
  • Roughly one out of three users consider some people important but don’t talk to them as often as they would like to. One out of three makes the potential number of users quite small. However, there is something else that I observed.

Do users want to get better at keeping in touch?

  • Out of all respondents, 60% said they would like to be better at keeping in touch. 20% users who identify as being good at keeping touch too would like to get better. This indicates that the app might be well received.

User Interviews

I conducted four semi-structured interviews to know more about user’s calling habits. The first participant confirmed all my assumptions. Out of the remaining three, two had differing opinions, and the last one didn’t seem like they’d use the product I had in mind.

Pain points help me keep in mind the most important issues to tackle later in the design process.

Pain Points

1. Mood: This ‘mood’ is not emotional headspace wherein a user would call someone because they’re in a happy mood. It means, that if a user realizes that they haven’t spoken to someone in a while, they may wait until they feel like.

2. Having to remember to call people: This is the most obvious pain point of them all. Most users believe that a schedule would greatly benefit them and act as an external motivator, but some do not like the idea and believe it to be impersonal.

3. Short term forgetfulness: Users sometimes forget that they had to call someone in a very short time. They don’t use a reminder app or pen and paper because it takes a lot of effort for something due in 5 minutes or earlier.

4. Not realizing how much time has passed: Sometimes, due to their schedules, an unusual duration of time passes by without the user talking to someone.

Problem Validation

Insights from the user research helped me create a better, more inclusive problem statement.

“Users have certain groups of people in their life who they want to keep in touch with, but don’t sometimes because they don’t remember to or sometimes because they don’t feel like at that moment.”

Competitive Analysis

Bond (iOS), Stay In Touch (iOS), and Call Reminder (Android) are some of the apps that offer similar functionalities.

I used to be dejected if an idea I thought to be original was already conceptualized by someone else until I read this, ‘the fact that it exists means that there is a demand for it and no one is doing it the right way yet’.

While these apps have the most features, they all lack certain crucial features that users need, based on user interviews.

  • Bond, for example, does not have callback reminders and does not allow feeding selective contacts into the app as opposed to the entire contact list.
  • Stay In Touch has a very outdated and cumbersome interface. It also doesn’t have non-call reminders and scheduling options.
  • Call Reminder, has useful features, however, the entire process is manual.

None of the apps have a smart reminder feature, something that adjusts the reminder countdown if a user contacts someone. Check the last section to know the logic that lies behind the design.

Conceptual Model

I use conceptual models to ideate about what could go in an app, or what types of actions can a user perform. Here’s the one I ended up with.

Usually, I prefer pen and paper over coggle.it and other tools.


I thought that the scope of the project does not justify the usage of personas at the beginning. However, upon sketching the concept models, I realized that there are four types of users, and if not full-fledged personas, a clear demarcation between these users would help me later in the design process.

I then came up with mini-personas¹ (both the term and the personas) and chose to base these on characters in the Wizarding World.

1. Mini-personas: When you realize you should have made user personas but now have to improvise. Cite me.
  1. Hermione: These users would benefit most from the scheduled reminders of the app. For the purposes of the mini-personas, these users are planners.
  2. Luna: These users would benefit most from the feature which lets them know how long it has been since they last spoke to their contacts. For the purposes of the mini-personas, these users are lost in their own world.
  3. Neville: These users would benefit the most from the quick reminders feature. For the purposes of the mini-personas, these users are forgetful.
  4. Mad-Eye: These users are those who would benefit most from the feature which lets them know how long it has been since they last spoke to their contacts. These users warrant a separate category because their habits are driven by their moods — a challenging factor to take into consideration when designing for them.


Again, I prefer sketching out quick ideas and creating as many variations as I can. I lost the other drafts, this is the A4 that I chose to base the designs on.


Once I felt that I had sufficient data to back my designs up, I used Adobe XD on my Windows laptop to whip up these low fidelity wireframes.

The bottom bar is exotic to me. I haven’t seen apps use it. It was a unique experience designing these screens.

These low fidelity wireframes were made keeping in mind the four types of users. Upon completion of the wireframing process, I showed these to a designer to review. The changes and suggestions are documented in one of the later sections.

Copy and Content

The app is not content heavy. Being a reminders app, there isn’t a lot to do in terms of copy. The copy in the app needed to be warm, friendly, and easy to follow. I had to word everything carefully. Labels and fields that could potentially be confusing needed to be simplified such that they are neither confusing nor condescending. For example, “Minimum gap” could be better understood as “Remind after at least 7 days”.

The names and images used for the content are from the Wizarding World as well. © JK Rowling

UI Design

Color and Typography

Blue, while the de facto choice for productivity tools such as reminders and To-Do’s, does not portray the warmth that is required for an app that places an importance on interpersonal relationships. I chose red for this reason. The base color used was the default Material Red with its HSB values adjusted to find a warmer, friendlier color, which was essentially increasing the saturation and decreasing the brightness.

I wanted the user to have a familiar experience. Roboto, being standard and familiar, yet versatile with plenty of weights to choose from was the perfect typeface for this design.

User Interface

Expert Review

As mentioned earlier, after creating the low fidelity wireframes, I consulted my colleague, a UX designer by profession. A few of the suggestions that were incorporated are,

  • Change the AppName heading to the activity heading. This way the user knows what screen they are on.
  • Don’t reinvent the wheel, use a time picker to let users set a quick reminder.
  • The FAB button moves to the right on a bottom bar. Try doing that in the Add Reminder Screen.

The second review came about before and after inserting colors and correcting typography. I consulted another colleague, a UX designer by profession. Here are a few of the suggestions that were incorporated.

  • The home screen is different. This inconsistency between contact elements might not be well received by the users.
  • [In the Add Reminders Screen] when the next reminder is due may be more useful rather than the relationship with the user. The former is not something they would already know.
  • The graph will require a certain level of data literacy. This might restrict the population of users.

These were the most impactful changes. Quite a few other changes were made the designs before creating the Prototype. At my discretion, I removed the add notes feature as I didn’t think it contributed to the app at the moment.


This was by far the most iterative phase. Even though I ended up making changes to the design based on reviews, there were way too many wrinkles, sometimes creases even, in the design that needed to be ironed out.

I had to create screens for intermediate stages of the app. Doing so did not take a lot of time as most of the screens were minor variations on what I had designed earlier. This time, I arranged the screens based on the feature or action that they belong to.

These screens are in fact the first revision after User Test 1, which is why you might see some changes.

You can see that the graph has been replaced with a calendar. Screens for the search feature were added, as were overlays for navigation, a screen that shows the notification in action, etc.

User Tests

I conducted user tests with 6 users and gave each of them the following seven tasks. The tests were short and tested the important features of the app. I chose not to include interacting with the notification as the actions are covered in the other tasks.


  1. You want to talk to Ginny Weasley at least once in two weeks. Set a reminder from the app to do so.
  2. You’ve already added a reminder for Rubeus Hagrid and you’re supposed to talk today, but you don’t feel like. Reschedule that contact for next week.
  3. Use the app to find someone who you haven’t spoken to in over two months and call them up.
  4. You are supposed to call Dean Thomas in the next 15 minutes. Set a reminder from the app to do so.
  5. For how long did you talk to Minerva McGonagall on 17th August?
  6. Make Neville Longbottom a favorite contact in the app.
  7. How many days this month so far have you called Minerva McGonagall?


The first user barely scraped through. The partial completions were based on conjecture, e.g. I might click on search and find that contact, or I would expect call logs to show up when I click on the contact.

The task failures were either because the user was unable to complete the task, or gave up because they found it too confusing.

I made a few variations and added micro-interactions between screens. Doing so, however, did not solve the issues. Users were still behaving the same way. The issues that P1 and P2 had, were largely the same. Debriefing them led me to find out the biggest mistake I had made.

You can do a lot with a contact. Call them by swiping right, reschedule if a reminder exists by swiping left, tap to select, tap to expand call log, etc.

Although the UI elements were consistent, the subsequent actions were not. After this design epiphany, I introduced only one additional screen. However, the impact it had was tremendous. A small change led to a huge overhaul in the overall Information Architecture of the app.

Users could now perform any task from any screen, wherever they could interact with a contact element, as opposed to the earlier hierarchy where only certain tasks could be performed from certain screens.

The Contact Overlay that improved the app.


I introduced a familiar UI element. The contact element from Android’s Contacts application. This rendered the earlier change redundant, the one where a user could select a contact to access certain actions.

P3 to P6 showed a significant improvement in task success rate. This led me to believe that the design was completed now. The next step would be development.

Here’s the prototype again, in case you would like to try it out yourself.


Don’t just review, test.

While designing at lower fidelities, a designer has to fill in the gaps. Perhaps that is why reviewing with my peers did not aid me to find the IA faux pas. Or perhaps it was a legitimate oversight on my part.

In either case, I concede that it may have saved me time had I tested the design with actual users early on, instead of focusing only on peer reviews.

If there’s a process, I should follow it, shouldn’t I?

Mini-personas were an inadvertent invention. While I don’t encourage following rules for the sake of it, maybe it would be wise for me to not deviate too much until I gain some more experience and would be comfortable calling myself a pro.

Or maybe it would be wiser to continue deviating to see what works, what doesn’t, and learn from failing often.


The irony of using technology to address something that may have been exacerbated by technology is not lost on me. While I didn’t begin with a benefit for the society in my mind, I have come to appreciate the implicit responsibility that designers and developers both carry and hope to think more along these lines in my future in tech.

Source link https://uxdesign.cc/43days-3e8cbbcf4013?source=rss—-138adf9c44c—4


Please enter your comment!
Please enter your name here