# Giving users a seat at the table: how we built our Android app

> Why user-driven development is key to building a great app.

Source: https://asana.com/inside-asana/how-we-built-android

## Giving users a seat at the table: how we built our Android app

A few weeks ago, we[launched our native Android app](https://blog.asana.com/2015/01/asana-for-android-has-arrived/), which had been in the works for months.We knew after our iOS launch earlier this fall, that this release was highly anticipated by our Android users and we really wanted to get it right. But no one on the team was an Android power user (at first), so we didn’t trust our product instincts the way we may have designing for web or iOS. We had a vague idea of the features required to deliver a great app experience, but the details were fuzzy. So we decided to do things differently: we relied heavily on our users throughout the development process, optimizing it around learning — collecting and incorporating feedback from a special group of beta testers early and often. What resulted has shaped the way we approach product development at Asana — not just for Android. We’re just getting started.

## Smaller MVP with room to grow

When we initially built the product roadmap, we knew we had a lot to learn. Sure, some information was available to us from the beginning — user research, competitive analysis, lessons we learned on other platforms, etc. But we immediately acknowledged that lots of new information would become available to us later. For example, our team was small, but growing fast, and we expected to have a couple of Android experts weighing in on key decisions soon. We also wanted to factor in any advancements in Android technology or design that Google was planning to announce later in the quarter. Most importantly though, we wanted to incorporate feedback from beta testers on the app as it developed.

So we negotiated down to a tiny set of features we knew we’d need in order to test the app ourselves. For us, this meant focusing on [Inbox](https://asana.com/guide/help/fundamentals/inbox). By only committing to building Inbox, we avoided the costs inherent in gaining consensus on longer term roadmap decisions. We chose to make those calls closer to the time of actually executing on them, when we’d presumably have more information available to us. We left plenty of room in our schedule to expand scope beyond Inbox for that reason.

## Design with the intention to iterate

##### Our approach not only opened us up to design experimentation, but also allowed us to move faster than usual.Knowing that our plans were subject to change based on the arrival of new information, we approached design with a light heart. Without the pressure to “get it right” straight out of the gate, we were free to experiment with fresh ideas and take chances that otherwise may have felt too risky. We considered our initial designs to be learning opportunities more than anything else.

Our approach not only opened us up to design experimentation, but also allowed us to move faster than usual. We didn’t bother with redlines or other documentation ‘work about work’ because we expected most things to change. Instead, our designer put together rough mocks and tweaked them in code alongside an engineer to save time.

Since we were starting with just Inbox, we were able to narrow our focus on one feature rather than designing an entire app end to end, which would have required a longer lead time ahead of implementation. Of course, we knew we’d eventually add more features, so extensibility was always top of mind.

## Extend the roadmap incrementally

Focusing on one feature first also allowed us to gather meaningful feedback from users early. We started with Inbox because we believed testing that feature internally would answer a lot of open questions we had about Android-specific use cases and allow us to make more informed roadmap decisions. Once Inbox was fully functional and decently polished, we distributed it internally.

Because Inbox only supported a single use case, the feedback we received was very focused and provided a clear signal for next steps. We heard things like, “Getting notifications about task updates is great, but I need to see the rest of the task for more context,” and, “Once I get a notification, I’d like to be able to create a task for myself to follow up.”

While it felt great to have more information than when we started, we knew we still had a lot to learn from real users. So we used the internal feedback to extend our roadmap a bit further out, but decided to hold off on committing to anything longer term. We would only build the features necessary to get us to our next goal, which was an app we could distribute to a small group of external beta testers in order to collect more feedback.

We added a couple of features on top of Inbox before distributing the app more broadly, but we didn’t build them all at once. Instead, we added each new feature one at a time and then collected feedback before moving on to the next feature. This prevented us from building more than what was absolutely necessary to reach our next goal of external distribution. It also allowed us to ship as soon as we recognized that our feature set was sufficient — we were never stuck with a large set of partially built features that all needed to be polished before shipping. Instead, we had a small set of fully functional and polished features ready to go as soon as we recognized our next MVP.

## Fast feedback loops with real users

Working in sync with users was rewarding because we got to see the impact we were making in real time, rather than building in the dark.Once we had the right set of features required to collect meaningful feedback from people outside our company, we kicked off phase one of our beta program. First, we invited a handful of friendly customers into our office to meet the team, eat dinner, and get access to the app. This was not only a great opportunity to build the foundation for longer term relationships we hoped to have with our Android community, but it also gave our team (not just user research, but designers, engineers, and PMs) a chance to see first hand how our work was received. It was an incredibly humbling experience to watch users stumble through certain interactions. We realized that many of the assumptions we were making up front were not always true and learned a lot about ways we could improve.

We kept in touch with these users over the next few weeks and incorporated their feedback into our roadmap. Our user research team used [Get Feedback](https://www.getfeedback.com/) to send out surveys gauging reactions to design iterations and new features every week. We also installed [Instabug](https://instabug.com/) to collect one-off bug reports and feature requests. The app was transforming rapidly for these users and they were excited to be a part of the process. Working in sync with them was rewarding for us, too, because we got to see the impact we were making in real time, rather than building in the dark.

Once the app was in good enough shape to collect feedback from a broader group of external testers, we kicked off the second phase of our beta program. This was similar to the first phase, but included a larger group of about 50 testers. We hosted another dinner, observed their first experiences with the app, and then continued to collect and incorporate their feedback over the next several weeks. We eventually expanded the group of testers a third and final time to maximize learning before launch.

## Knowing when to launch

Each week we asked our users to rate their experience on a scale from tough going to totally awesome.To help us determine the best time to advance our app from internal testing to a small group of external testers to even larger groups and then eventually to launch, we used a sentiment score that tracked our progress.

Each week we asked our users to rate their experience on a scale from “tough going” to “totally awesome.” Initially, we saw huge gains in the sentiment score after each update to the app. This wasn’t surprising since we started with just Inbox and then quickly added features that significantly improved the overall experience for the majority of users.

Eventually, though, we began seeing diminishing returns. At that point, our updates either marginally improved the experience for everyone (design polish) or significantly improved it for only a subset of users (editing capabilities for power users). For us, this was a good signal that it was time to launch. We knew we’d learn much more about how to make great leaps again once we got feedback from users at large.

## Never stop learning

We are by no means finished.One of the best parts about giving our users a seat at the table was knowing that we had cheerleaders waiting for launch with open arms. That made it both less scary, and more exciting.Hundreds of beta testers were already getting a lot of value from the app for months,and we couldn’t wait to let everyone else in on the new app. Our work is by no means finished; some of the most interesting insights are yet to come so if you’re an Android user, we’d love to hear from you. This experience has taught each one of us how important it is to involve users in app development early, and it made the process of working on the app more fun and more personal for us, too.

_A version of this post_[originally appeared on Medium](https://medium.com/@samgoertler/379e3033cbfb)_._

Want to help us build the next generation Asana for Android? [Join our beta program](https://blog.asana.com/2015/03/lets-build-asanas-android-app-together/).

- [系統管理主控台中的微型架構](/zh-tw/inside-asana/microframeworks-admin-console)

工程

每個 Asana 部署都有一個系統管理主控台。 IT 系統管理員可以在此處設定公司使用 Asana 的方式，例如調整密碼要求、角色和權限、是否可以從 Dropbox 附加檔案，以及在預設情況下誰可以看見新專案。隨著 Asana 的發展，系統管理主控台累積了多年的自訂邏輯和臨時拼湊的解決方案，導致建立和維護管理控制項的成本越來越高。 以其中一項管理設定為例： ...

- [以規格為導向的開發：優點以及我們在三個月後學到的內容](/zh-tw/inside-asana/spec-driven-development)

工程

#### 主任軟體工程師

三個月後，我們更清楚地瞭解了新增的架構在何時有幫助，以及在何時成為阻礙。我們的一位工程師正在準備資料遷移，並決定使用規格導向開發 (SDD) 來規劃工作。 SDD 的用意是幫助他們及早發現疏漏，使方法更易於審查，並為客服人員提供明確的方向。 最終的計劃非常詳細，從紙面上看來相當合理。 它將工作組織如下：問題 → 研究 → 規格 → 審查 → 實施 → 驗證 ...

- [我們在 2 週內完成了 Enzyme 遷移。這本應花費五年的時間。](/zh-tw/inside-asana/migrating-off-enzyme-2-weeks)

工程

我們最近使用 AI，在大約一次衝刺中完成了多年的工程工作。 以下是其方法，以及為什麼它改變了我們對可能性的看法。五年問題早在 2022 年，我們就著手將 Asana 的前端測試套件從我們老舊的測試庫 Enzyme 移轉至 React Testing Library (RTL)。 Enzyme 已經失去社群支援，無法與較新版本的 React 正常搭配，並且鼓 ...

- [打破致命三重奏：Asana 如何看待代理式 AI 安全性](/zh-tw/inside-asana/how-asana-thinks-about-agentic-ai-security)

工程

#### 主任安全工程師

代理式 AI 帶來了一類業界尚未解決的安全風險。 以下是 Asana 對此的看法，以及我們在所有 AI 功能中保持的安全性不變項。問題代理式 AI 系統不僅僅是回答問題。 它們會閱讀文件、採取行動以及跨工具進行協調。 它們能做的事情越多，可能受攻擊的範圍就越大。與傳統代碼不同，LLM 有一個特性，使這一點從根本上變得困難：它們無法可靠地區分指令和資料。 提 ...

- [Giving users a seat at the table: how we built our Android app](/zh-tw/inside-asana/how-we-built-android)

工程

A few weeks ago, we launched our native Android app, which had been in the works for months.We knew after our iOS launch earlier this fall, that this release was highly anticipate ...

- [工程](/inside-asana/engineering-spotlight)