Mike & Zephrin are the serial entrepreneur co-founders of Tada. And like most tech startup co-founders, the bulk of their work happens on their computers fragmented in to a number of services. Email, Google Docs, Notion, Figma, Invision, Miro, Slack to name a few. And with the recent global shift to remote, much of the traditionally synchronous in-person work has also moved online. All of this has brought on an onslaught of notifications and async messaging whose effects we're only just starting to understand. Through their own lived experiences and by talking to their friends & family, they realized that they weren't alone in feeling this communication overload & anxiety.

Team Tada got some preliminary help from one of their past startup's designer to explore their ideas. They presented their early concepts and thinking to some of their past investors. When they noticed their message resonating with a lot of folks, they decided to come to our team at MetaLab to better define their vision and design their MVP.

Our team had a remote kick-off with Mike, Zephrin and other members of the Tada team. They're a pretty small self-funded team, so everyone was present. This was a pleasant deviation from the norm! We discussed their vision at length, understanding the problem they were trying to solve. As a (nearly) fully remote company for over a decade, our team at MetaLab was well aware of these issues in our own work flows. From the get go, Mike knew that at a high level, they were trying to manage the communication overload problem with some form of a meta-layer that would live on top of all your communication platforms (Slack, Email etc.). Their version of this meta-layer was a personal task management app that would somehow magically populate itself with things that need your attention. We helped them solidify their vision through some hypothesis brainstorming.

Since the project was on a tight schedule, with a limited budget for research – we did some of our own internal research to understand potential user behaviour and limited external user testing in later stages of the project. I'll expand more on the challenges of doing this later.

One common thread across these interviews was somewhat challenging (more on this later), but also an important point for us to keep in the back of our minds as we were thinking about what Tada could be – Task management is not a one size fits all thing. While there may be commonalities between the processes people use to stay on top of their communication and tasks, it's differs from person to person.

One other way we use our own lived experiences as knowledge workers throughout the course of this project was collecting a sample set of tasks that are on our plates on an average day and cataloging them in a notion doc. Everyone on our team as well as Tada contributed to this. This gave us a wide spectrum of sample everyday tasks from people working in design, project management, development, business development etc. The goal was to understand the nature of the kind of work we're dealing with. Along the way, we also looked at the role a conventional task list plays in our workflows and learnt a few things:

- lists are outdated a soon as you create them (i.e., status or context changes)
- lists are more useful when you attach context (e.g. chat discussion, link to work)
- lists should be a living thing, always updated and associated data/ people
- lists should be more like a project management tool

These things, while arguably subjective in nature given the small sample set, were quite helpful for us to define the vision, prioritize features we'd work on and stress test our wireframes against.

After discussing the user pain points and product hypotheses with Mike & Zephrin, we set out to build on their initial concept of a live-context-updating task manager. The live-context-updating bit is just a fancy way of saying that any piece of context that the task is based on (say an email thread, a slack message, a figma document etc.) would always stay updated.

Tasks are not static. The context around a task isn't either. So why are traditional task management apps treating them that way? One of our hypotheses was that the big reasons one jumps between different apps during their work day is because they want to know if something 'new' has come up. The phantom notification anxiety. The other being that the 'old' is spread across many different apps. We refined this vision statement over the course of the project, but this is what we ended up with:

We also defined some guiding principles for our upcoming phases of work:

With the product vision defined, we collaborated with Tada to come up with a framework for Tada's MVP.

We'd later test assumptions with some external user testing recruits with the help of Team Tada.

At this point, we had a lot of our initial assumptions in place as well as a direction in which we wanted to take Tada, but not a ton in terms of the feature set we'd be working on over the next 2.5 months. So we took some time as a team to work on some Tarantinos. Think of a Tarantino as a day or so long design-athon. We take what we've learnt so far and try to get some of our product ideas into a semi-presentable state so we can share these with the team to get their feedback and we can use these to inform our future design decisions.

We'd later test assumptions with some external user testing recruits with the help of Team Tada.

Much like Tarantinos, the goal of this next phase of initial exploration was to uncover possible features that warranted deeper investigation, either from a technical perspective or from a feature usefulness perspective. As you can see, we did a lot of early exploration on this project because during this phase, since we were also actively looking for ways to separate Tada from the competition. This wasn't just for the sake of it, but because the fundamental philosophy of live updating tasks required a ground-up relook at task management. Being a remote team, the bulk of this was done async. Over the course of the 3 months on this project, I would go on to record just under 50 loom video walkthroughs of my work and feedback on my team's work.

After the Tarantinos and the priorframes had given us some clarity on what Tada could (and shouldn't) look like, we held some jam sessions with Mike and Zephrin and collaborated on our general architectural philosophy. We used this to develop the task funnel – the pathway for a task to end up in Tada. The core components of this funnel were:

1. Dynamic task input sources, aka external communication apps and manually inputted tasks
2. Task classification engine, i.e. the triaging mechanisms
3. Task manager

When it came to the task management aspects of Tada, we wanted to find the sweet spot for Tada on the spectrum of task managers going from unopinionated (Like a handwritten checklist) to opinionated (Basecamp, Asana etc.). Our inclination early on was to provide a lot of customizability in how one could manage their tasks going so far as to explore smart buckets that one could program to handle your incoming tasks, but we cut these explorations from our scope to focus on an MVP experience that could better accommodate these in a future version of Tada. After much exploration and iteration, we finally decided on a spot somewhere in the middle of the spectrum and a simplified architecture with 3 top level components:

1. Navigation - Now, Later, Done
2. Task List
3. The Task Details Sidebar

In a past life, I used to work as a Product Designer at Flow – a design focused project management tool by the folks at MetaLab. So, when the opportunity to work on a list of tasks came, I was quick to jump on it. It suffices to say that I underestimated the added complexity of live updates a little bit. On the surface, it felt like just a simple task list. But upon much reflection and discussions with my Design Lead, Ali – I realized that I needed a deeper understanding of the meta data associated with a task, in order to make informed decisions on which way to go with this list.

I also looked to best-in-class apps in this space (Things 3, Todoist, Trello etc.) to research patterns I could learn from.

Once I had the approval for the task list wireframes, I also looked into in-app task creation. We were positioning Tada as a space where tasks from other communication platforms were going to  be tracked and actionable, but allowing people to create their own tasks and link them to an external context was also something we wanted to enable.

One of the more challenging aspects of this project was the task details view. Much like the task list, the task details was to be a space where live updates would play a major role. I was responsible for the concept, and subsequent iterations of Task Details.

Mike, Tada's co-founder, had indicated to us during our discussions on task details that while we were targeting the solo Tada user for the MVP, he envisioned Tada to organically ease into the multiplayer use case. Keeping this in mind, I tried to explore ways to make the details view feel like a workspace of sorts. A one-stop place for a task (and hence work) and all of it's associated contexts – whether of the live updating external kind or the attachments kind *including* conversations around a task (more on this later).

I organized some considerations we'd need for designing how someone would interact with a living piece of external context like an ongoing email thread or a slack message to a task. This included some research into the possible scenarios that one would be using these contextual attachments. An earlier version of the details view had a feed like structure where the task meta data would stay on top, and any updates would be sectioned off underneath - including context updates like a new email on the chain or a new slack thread reply. But this reliance on a feed structure only added to the information overload problem Tada was trying to solve. We continued iterating on the way we treat the external context boxes and finally arrived at a more static attachment like treatment with dynamic content within them. I'll add this though, I now have even more respect for well designed email clients.

This was probably the coolest aspects of this project for me personally. This set of sprints was dedicated to looking into the issue of notification emails from web services like Invision, Notion, Google Docs etc. Initial research told us that a lot of the work & communication that reaches ones inbox or messaging service is from automated notifications that one 'needs to look at, approve or respond to'.

The idea of being able to respond to, say, Google slide comments within Tada without having to go to google slides to view the context of the slide was floated around during our kick-off. In our initial research, we'd also looked into the concepts behind Dynamic Email ([AMP Email](https://amp.dev/about/email/)) so we knew that we could leverage some of it's philosophy within Tada. I explored a simplified version of this flow and shared a loom about how I envisioned this to work with Tada's Mike. The goal was to understand the technical limitations I was working with. With the go-ahead from Mike, I continued my exploration into smart embeds.

We were about 2 months into Tada when we were ready to start looking at the branding at visual design of the app. After a kickoff session with Tada, and some direction on the direction they were leaning – we set up a playground for the designers on our team to riff on each others explorations. Matt, Principle Brand Designer at MetaLab, was heading the brand side of things and had started working on some logo marks. And parallel to Matt's work, me and Ali started exploring ways how some of these WIP logos and mood boards could extend to a high fidelity visual language for Tada. Matt would even use some of our modifications and feedback on the logos to further his brand exploration. All in all, it was a pretty collaborative process that pushed all of us to further our craft. We chose some core flows like viewing task details and some sparse pages like onboarding to see how well we could apply a brand to the product and reinforce it at the same time.

We presented these to Team Tada and continued refining the direction. While my instincts had minimalist bias had pulled me to one of my other explorations, upon reflection and feedback, I was convinced of the utility that the peppier & arguably friendlier exploration had. It's important for me to call out the amazing collaboration we had with Mike & Zephrin throughout this phase. The brand was Zephrin's department and Mike was responsible on the product end and they were both very pleased with our work.

With the design direction approved, all that was left was to apply it across the board. Important to note that we also took this as an opportunity to double check some of our most basic assumptions from earlier in the project. Konstantin, the Design Director on this project, recommended that we look into the task details one more time.

The assumption that we'd been operating under was that anyone looking to get more details about a task would click on it. Fair enough? But when we spent some time with the question that Konstantin had posed – we realized that the live updates change the dynamic a little bit. The click to view details is a fairly common pattern across web apps, but this being the web, maybe there were ways we could optimize Tada for quicker parsing of these updated details? After a few revisions, we decided that the details view as a sidebar had advantages beyond what were obvious to us right now at the MVP stage since it would scale easier. But we used the learnings of this exercise to explore some hover states for the task list.

We began applying the visual direction to the wireframes and continued refining it along the way. We also took some time to look into bringing Tada to life by doing some motion studies on key interactions. Here's where we landed after everything was said and done:

Tada was super happy the results of our 3 month long project. So much so that they extended their contract to include some of the dev efforts of building their MVP. I helped with some minor updates to the marketing page and QA of the MVP they were working on. They are in private Alpha right now, and have 2000+ people on their waitlist on last count.

Attaching an interactive email to a task was quite the learning experience for me. Unlike comment threads on messaging apps, email functionality and protocols have a vast number of use cases and boiling it all down to the essentials was something I strived for.
‍

Designing anything without researching the who/what/when/why behind the problems one is trying to solve is like trying to draw a portrait while blindfolded (please excuse my terrible analogies). When faced with time or budget constraints for research, we tried to use simpler and quicker in-house subjective interactions with people within MetaLab.
‍

This was not design related but working during an ongoing pandemic was pretty tough.

When the conditions are right for it, sharing how you work can be a great asset and can communicate your ideas and rationale more convincingly than a polished deck can. Obviously, this doesn’t apply to all scenarios, but my take-away form this is that I don’t necessarily need to get anxious about unpolished Figma files like I have been in the past
‍

Over the course of this project, I realised how important it is that branding and interface design shouldn’t be done in isolation from each other. Any digital product that wants to stand out for it’s exceptional design needs close co-operation between the people who are designing its brand and the ones who are interpreting it for the product.
‍

I’ve already mentioned this before, but task management remains an ever elusive beast that isn’t a one-size-fits-all thing. That said, it was extremely gratifying to work on this problem from the ground up.