Finally, I decided to tackle the problem head on, to redesign the way people interact for scheduling meetings in different time zones.

Everyone I interviewed agreed that it’s a pain to find common time slots for meetings, both domestic and international, especially when more than two people try to coordinate; but not just because of time zone differences. The drawn-out nature of communicating by email made it even more annoying.

Match Time minimizes the back-and-forth time it takes to schedule meetings between two or more people. It is extremely efficient because it cross-checks their calendars to optimize availability.

Even without sharing calendars, the app will find the most convenient time to coordinate a meeting without anyone having to pay attention to time zones, daylight-saving time, or holidays. It completely eliminates the headache of calculation variables.

 

• The users who tested the app rated it from 8 to 10. 
• 100% of users liked the clear design and found the app to be user-friendly.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I started by observing my own entourage. My friends, coworkers, and family live in different countries. After interviewing them in the manner of customer-development, I realized that their biggest common complaint was about all the back-and-forth. It took too much time to do what, intuitively, should be a simple task. Even more annoying than the process of coordinating a mutually agreeable date and time were the multiple follow-ups by e-mail to confirm them (up to twenty-five emails to reach a compromise); a tedious waste of time.

As a result of my customer-development research, I made a list of user needs based on this example: people who want to coordinate meetings across different time zones don’t want to annoy the other participants with time-consuming and tedious work. Instead, they want to enjoy fast, friendly, simple, and smart notifications on their mobile devices.

Like a “moodboard” in Visual Design, I have collected and documented different sources of inspiration to support my point of view and find the best way to approach the problem.

By establishing a customer point of view, I could put my product in the context of a real-use scenario employing storyboards. By showing how users will interact with the future product, I was able to design it in a way that consolidates each individual feature in a holistic way that achieves the overall goal of the app.

The storyboards were powerful tools that led to a paper prototype.

In the first prototype, the user selects his contacts and syncs them to the other users’ calendars. (Calendar data are shared to allow the System to coordinate a mutually convenient time. The data are not visible by anyone.) Next, the user sends his contacts one of the suggested time slots displayed by the app. If one contact declines that slot, the app generates new slot. The only task requested of the recipient of the notification is to Accept or Decline.

Strength:
• Fast process interaction between parties
• The user don’t need not be aware of time zone differences ones.

Weakness: 
For best results, users have to share their calendars.

In the second prototype, the user can convert the time from one location to other location(s). With a visual timeline linked to the user’s calendar, the user can swipe up and down to check the correspondence of the time in different countries and send his contacts whichever time slot he wants.

Strength: 
The user handles the time he wants to share by comparing his local time with his interlocutor’s local time on his own calendar.

Weakness: 
This version generates more back-and-forth and requires a bit more effort for the user.

I tested the paper prototype with five users and made changes according to their feedback with each new test. So, I was able to improve the interface gradually. The heuristic evaluation helped me to prioritize the changes.

Further, some insights I found from the test:

I revisited the goal to make sure the design served the users’ needs, and I made a decision about which prototype I would develop further.

I spent a lot of time with the paper prototype because it was fast and easy to iterate. It was also easy to get feedback.

Therefore, to save time and respect my deadline, I decided to go deeper in the flow by sketching the skeleton of the app on paper, instead of to polish a wireframe with a digital tool. (Popapp™ could be a good alternative for a low-fidelity prototype).

I made a wireframe of the main screens on Illustrator™ to get the direction, and I designed the prototype on Proto.io. In this case, I produced the prototype to define the interaction and for test purposes. I didn’t want to spend too much time in visual design.
In a more commercial project, I would probably spend more time creating my design on Sketch™ and Photoshop™ and add the interaction with a prototyping tool.

I distilled the results of two user tests to fix bugs and make a list of changes. Following the results, it made sense to design two versions of the “meeting with” screen and to test it.

Now the prototype was ready for a final usability A/B testing. 

After writing the introduction and the list of the tasks, I tested four users on usertesting.com.

The result of the test clearly demonstrated a better understanding of the design A. The users took less time to figure out what to do on this A page and how it worked.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I didn’t travel the world but I made a different personal and professional journey.

I travelled in the world of empathy and the emotion by helping, listening to, and trying to understand the mental model of my peers. How do they think? What do they see? People were very collaborative in the process and impatient to get a tool to help them.