Introducing Asana’s Fall 2024 Release. Discover what's new.Explore now
Welcome to our Meet the Team series, where we interview a member of one of our Engineering teams to learn more about what they do and how.
In this post, we sat down with Mobile Engineering Lead and people manager, Bella Kazwell. Bella works across the Engineering organization to think about programs and their execution, and to support her team. Read on to learn about the Mobile team’s app redesign, their mobile “squads”, and why boba and board games are a big team tradition — in Bella’s words!
About a third of Asana users experience the product for the first time on a mobile device. The mobile app is our opportunity to show users what Asana can do for them, right off the bat. Our team builds the Android and iOS mobile apps for Asana (who would have thought!). The mobile app is a really nice introduction to the product because it shows the person upfront the basic things that they need to get done, and allows them to see if they need additional power features (like Workload), which is what would lead them to use Asana on desktop, where they can explore on a deeper level. It’s crucial that mobile and web work together seamlessly, so users can pick up where they other left off on any device.
The recent redesign of the mobile apps was really exciting. When I look at screenshots of the old app, it’s so clear the big improvements to the UI! This was a win all around — we saw improvements in usage metrics around global collaboration and visits. Local metrics like task completion, project creation, and inviting teammates also went up. I believe this big jump in metrics indicates that we are helping our customers experience more value with Asana.
Customer feedback is so impactful. Seeing tweets or messages from customers after we launch a new feature is really exciting. It helps us see that what we’re building makes a difference in our customers’ work. One recent example is when we launched Dark Mode for iOS. This was one of the most requested features in our community forum, so we decided to prioritize it.
Just like the rest of Asana Engineering, the Mobile team is mindful when it comes to technology to work with. The process usually involves writing a proposal in a design doc and having it reviewed by stakeholders before we make a decision.
The Android app was initially built in Java, but we recently moved to Kotlin because it’s concise, less error prone, and has better language constructs. Moving to Kotlin reduced errors while writing code and resulted in fewer bugs in production. It also increased code quality, and improved developer efficiency. In the coming 6 months, the Android team is focused on rearchitecting the app to make it easier to onboard new engineers and for them to contribute. This work involves moving to modern Android architecture components and testing frameworks.
The iOS app is built mainly using Apple technologies such as Swift, Xcode, and various iOS SDK frameworks. We also use some third party libraries and tools.
The server-side infrastructure used by both Android and iOS apps is built using a combination of server-side services written in Scala and Typescript.
In addition to the redesign, a lot of work has been focused on user adoption. We want to make sure our users who discover Asana via the mobile app onboard successfully, and get the most value possible out of Asana as quickly as possible. Some of this includes showing in-product cues for onboarding, the ability to invite teammates to Asana, and showing the value of Asana to users by guiding them through sample tasks and projects.
Asana is so useful for bug triaging. One of the more unique ways we use Asana for this is with our 700+ global employee base. Everyone at the company uses the product, which means that people who are not in Engineering can provide feedback and be looped in to the entire process of logging, triaging, and solving that bug. When the PR makes it to production, any employee can see how their feedback ultimately helped improve the app. When we discover a similar problem later, the original task can always be used as a reference, so all of the context is there and you don’t have to go back to the original task. The original user knows their bug is being worked on, and the engineer who is making the change can link to the task in Asana.
From a personal perspective, I live in my Asana inbox. I can always rely on it to keep me up-to-date because things that are due that day appear in my inbox, so I know to complete them or change the due date. My inbox is also where I can see status updates and how things are tracking for the day. I see links to tasks and the work that’s happening around them. It’s so helpful that tasks get assigned with due dates so things don’t fall through the cracks.
Below, we’ve pulled a screen-grab of how we triage and prioritize a bug reported by an Asana user. The bug gets a P1 priority, an assignee, a due date, and then gets multi-homed into the Android Sprints project to be worked on during next sprint.
Recently our web teams have started shifting to being whole feature teams, and are now building their solutions for both web and mobile. This means that more engineers have been contributing to the mobile codebase. One web engineer, Shen, has worked on Android before, so not only did he implement the feature for his team, he also provided strong insights on what would make the Android codebase easier for more engineers to onboard onto and contribute to. We’re very excited that Shen has just joined the Android team full time, from New York! It’s a great example of the internal mobility engineers have at Asana. We also just hired a Head of Mobile, and we’re so thrilled about them starting!
One of our favorite traditions is mobile couch time. It’s a casual hangout every Friday afternoon and an opportunity to show off what they’ve worked on to a small, supportive group. People talk about things like the most interesting bugs they’ve encountered or funny app store reviews. For the last two years, our team has sponsored the Droidcon conference in San Francisco. We love the opportunity to connect with other passionate developers, while talking about why we love Asana, as a product and company!
The mobile team also gets together outside of the office. We love to go for meals (and boba) together. We’ve done bubble soccer, foam archery and woodworking workshops too!
There are so many things happening in Asana Mobile right now, so it’s fun to be a part of defining where we go. On the vision side, with our focus on adoption, it’s so gratifying to have every project the team works on yield tangible results. More importantly it means that our users are able to collaborate better. Within the Mobile team, we are evolving how we staff projects and how we collaborate across platforms. This means that engineers now have an opportunity to own the whole feature and think full stack and across.
On the company side, it’s exciting to see the program teams’ perspectives shift from building a web feature to thinking about the whole user problem, and how the solution can transition seamlessly between web and mobile. We’re collaborating more efficiently and always doing what’s best for our users. I love seeing all this change and I’m excited to experience the outcomes.
Work with Bella and the Mobile team at Asana! Check out our open roles and apply today.