I’ve been interested in productivity and self-development for a while, so when I had the opportunity to work in this field, I jumped on the occasion. The issue was … our project brief stopped there, with this big word: “Productivity.” What could we possibly do?

Indeed, a productivity-oriented product could be so many things. Habit tracking, personal finances, team collaboration, project management, documentation, and many more. With only 3 people and a limited time-frame, we had to focus on one area. But which one?

Let’s look at the market…

Currently, the market is extremely competitive, and close to saturation. Luckily, it’s also very diverse, with many niches to explore. Maybe one of them has room for us.

Our exploratory research revealed a few gaps in the market which we could explore:

• Artificial intelligence allows for more automation and personalisation

• New augmented reality platforms reinforce the existing shift toward mobility

• Most importantly, there is a huge shift toward remote work in this post-COVID era

Then, we looked at top competitors in various sub-categories:

What do users need?

At this point, we aimed at the widest possible audience: adults of working age, worldwide. We also had the intuition that young professionals would be more open to adopting new tools. With this in mind, we interviewed 10 users.

Without surprise, many users mentioned existing tools, stating their preference for:

• Convenience: free, preinstalled, or commonly used would be near impossible to replace

• Flexibility: users have conflicting workflows, and tools should adapt to them

• Positive feedback: users want tools that encourage them

• Human interaction: after months in lockdown, users miss their coworkers!

“In less than three clicks, I should know what’s going on.
[…] That’s why I really like dashboards.”

However, if this interview informed us on our user’s motivations, we still needed more data. We released a survey on multiple social media and forums, which revealed surprising results.

First, we had to refine our target audience. It’s still OK to target professionals, but only as a secondary target. Our primary one should be students.

The next information was expected: many users switched to remote work during the lockdown. As a result, they need help organising their day.

Another surprise was the huge majority of users wanting very simple tools, when we expected advanced ones that included many features. The exact opposite was required: something as simple and flexible as pen & paper.

How can we help?

All this precious research being done, we had a better picture of our users. We took that picture, and turned it into personas.

(click = big)

Because of our time constraint, and since this was a first version, we decided to focus on Angela, the at-home student, and looked at a usual day she might experience. We keep the other personas for a future version.

And finally, finally, we knew what we would be doing. We just needed to look at that opportunity row in Angela’s day, and there was our problem:

The at-home student needs a tool that organizes her schedule, reminds her of her tasks, and provides her with a report of daily activities, so that she has more time to nurture a positive mindset, communicate with her peers, and enjoy a better work/life balance.

Along with this, we adopted some guiding principles for our design, based on our research, our personas, and our own values as a team. Our product would be:

Let’s make it happen!

Once we knew our problem, it was time to work on our solution. The first step was a quick brainstorming session, in which we discussed potential features, then we sketched a few concepts. Two of them had more potential in our eyes, so we turned them into paper prototypes, and presented them to a couple testers.

Concept A

(selected screens; click = big)

Concept B

With those in mind, we conducted a new brainstorming session, in which we decided which features would make the cut for a MVP, which would be nice to have, and which should be kept for future versions or eliminated entirely.

Also, we tried a few things with our labels. For instance, many power user apps have a past/done area called “Logbook,” and a draft area called “Inbox.” These come from the GTD methodology, but formative testing showed us they’re confusing. We renamed those two “Archives” and “Drafts.”

Thanks to all that feedback, we built mid-fidelity wireframes. Then new ones. Then new ones. Let’s look at the last version:

(selected screens; click = big)

You might note the navigation changed from our concepts. This was an important area for us to focus on. At first, we considered we had a few screens we thought were more important than the rest, and placed them in a bottom navigation, while other ones were hidden in a sidebar. But this was confusing.

In a second step, we placed everything in the sidebar, with the timeline up-front. But then, testers stopped using the menu altogether. The solution was to streamline our navigation to the point it could be condensed into this bottom navigation.

Meet Doable.

Let’s put it to the test.

As mentioned, we ran informal formative testing along the way, but with this mid-fidelity prototype, we ran a proper usability test. We gathered 5 potential users that fit our primary persona, and gave them 3 tasks to review different aspects of our app.

“A lot of task managing [apps] are either for kids in school or are like Premium Plus for working adults. So this is like a nice in-between model.”

We can say it was a success. All our users completed all tasks, and found it easy to use. However, there is still areas to improve upon. Notably:

“But it doesn't have any of the specialized features […] like productivity monitor or natural language processing when you add a task.”

What’s next?

This project is over for us, but we didn’t want to leave it without a few recommendations for those who would follow in our steps.

1. Explore possibilities for the “Drafts” section. Since only power users look for it, either rename it “Inbox” and keep it as an advanced feature or … remove it entirely?

2. Clarify the “Tags” feature. Maybe add a “Description” field in the tasks details to remove the ambiguity, or explain during an onboarding process.

3. Copy the success of the “New task” button. Other call to actions would gain from a similar clarity, especially in the task creation process.

What I learned.

Since I was project manager on top of being designer, I exercised both roles at once, and had to clarify what was my role for each decisions. Particularly, it was interesting to see how both roles interact when we had a mid-project team change and I had to on-board a new teammate. This reinforced for me the importance of good documentation.

Also, I wanted for this project to improve my interviewing and testing skills, so I did most of them myself. I focused a lot on avoiding bias and other common errors.

Finally, this wasn’t my first remote experience, but I had to cover really big time differences. The team was itself on multiple timezones, and our audience was worldwide, which means I had to juggle with up to 12.5 hours of differences sometimes. This forced me to work on my own time management. =)

© 2020 – Alexandre Ultré