Starting From Nothing
How the Tanda Mobile App came to be
Before 2017, Tanda did not offer a mobile app. It was clear that building a mobile app was an important step to take to make our product more powerful. We now have an app with more than 40,000 unique users, this is an outline of how we built a product from nothing to an integral part of Tanda’s ecosystem.
What is Tanda
Tanda is a SaaS product purchased by employers to make their workforces more successful. Tanda handles staff scheduling, timesheets, time-off, and everything in between.
An important thing to note when talking about our mobile app is that Employers pay us to use the entire Tanda ecosystem, meaning the App is free to download and use by all employees in the system.
Motivation
A big part of what our product offering was missing in comparison to our competitors was a mobile app. Building one was clearly a necessary step to take, as it gave us an opportunity to build a powerful platform that we could use as a foundation for more innovative projects once we have the Tanda ecosystem in the pocket of every employee and manager in a business.
The Tanda product team has three simple principles that we aim to make all our products align with:
A mobile app would directly improve all of these principles. If we put data into managers hands, they can make a decision without going to the back office to check a computer. The app will give us a platform to show employees their most up-to-date roster, timesheets, and more, improving trust. Because of its accessible nature, the app will encourage employees to be more engaged with their workplace and keep any important details such as unavailability up-to-date.
Research
Being a brand new product, it was important that we built a solid foundation that would encourage people to adopt the app. To get an idea of what we should prioritise, a lot of research was done into the existing market for similar products.
I downloaded and used the apps of every competitor I could find to get an idea of what features they had, how their app looked, and how certain processes worked. I also read through competitor’s negative and positive app store reviews to figure out how they won people over, and how they disappointed people. This was a great way to get an idea of trends and the existing patterns that were in use.
We conducted interviews with current Tanda users, our sales team, and even users of competitor’s products to get a better idea of what people would find useful and important in a mobile app. We also sent out surveys to employees and managers. The results from these surveys gave us a few trends to work from, but the data was very surface-level — We now knew what they wanted, we weren’t able to ask why. Later conducted interviews with employees and managers have solved this issue, and we were able to assign reasons to our trends.
We got a few key takeaways from our interviews:
- Managers want to be managing — That is, they want to use the app only when it directly benefits how their shift is running. The app should be unobtrusive and urgent tasks should be done quickly and without much thought.
- Employees want to trust when they’re working, make sure their leave and unavailability is kept up-to-date, and check that their timesheets are going through correctly. They were more concerned about trust and knowledge, and were much less concerned about urgency.
At times it was difficult to design for two completely different groups of people with wildly different needs. At one point, we did consider building two separate apps— one for managers, and another for employees. In hindsight, I stand by our decision to build a single combined app, as we’ve found better ways to split manager and employee concerns (Such as the updated Overview screen discussed further below).
Based off the research above, we set out a selection of the foundational features we’d like to have built for the app over the next year. I’m proud to say that when looking at this list a year on, we’ve shipped a huge chunk of the features we’d initially outlined.
Design
The first feature designed for the app was the Work screen. You can read all about the process for designing the Work screen here. The Work screen gave us an initial design style that we could build upon as a basis for the rest of the app.
Because of the professional nature of the app, and the fact that it was likely to be used by all kinds of different demographics, I was quite conservative with the design. I was heavily inspired by the settings apps for both iOS and Android, because I wanted the app to feel familiar and simple enough that it could easily be picked up and understood. Apple’s Human Interface Guidelines and Google’s Material Design were both great help to give me a better understanding of what best practices to use when designing mobile apps.
In certain situations, we use different components for our iOS and Android apps, as their users would expect that pattern — For example, our iOS app will often have a key action in the top right of the screen, whereas our Android app has a Floating Action Button. Each pattern is recommended in the OS’s respective interface guidelines mentioned above.
Navigation
With a spread of all kinds of different features, it was and still is a struggle to figure out the best solution for navigation. I believe that a tab bar is the best choice for top-level navigation, as it’s used across top apps (Such as Instagram, Facebook, Twitter, and Spotify) and is recommended in both iOS’s HIG and Google’s Material Design.
The larger struggle became choosing which specific screens to use as the top-level navigation tabs. I found a few issues:
- We have to add tabs sparingly, as it’s recommended to have a maximum of only 5 tabs.
- Knowing that users of this app could be less tech-literate, I didn’t want to add temporary tabs that would likely be removed later on, because this would have the potential to confuse users and lead them to think that the feature had been removed, when it had just been relocated.
With both of these points considered, we’ve kept the app to three tabs in its current state, and have made other adjustments to top-level screens to reduce the number of tabs needed. We do have future plans to add more tabs, but with these features a long way off, the tab bar will remain the same.
Iteration and Improvement
Because the app is always evolving, it was important to revisit previous features to make sure they continued to work as the rest of the app grew. Over the time of the app’s life, the Overview screen in particular has been adjusted many times. The most recent addition to this screen was the tabs at the top. This was to improve information hierarchy and separate functionality, as information overload began to become a problem for the previous iteration of the Overview screen (The second screen below).
With this update, we could now justify making the Overview screen the default when the app opens. Like I mentioned before, Managers want to be able to quickly and efficiently get a task done in the app. A manager can now open the app, identify when a staff member is late, and call that staff member, all in only three taps.
In the early days of the app, we struggled with getting feedback from users. In a couple of hours, and using Zapier and webhooks, I built a simple feedback form into the app. Over the past year, we’ve received more than 2000 pieces of feedback. Combined with analytics, we’ve used this data to identify a few problem areas in the app, such as when features weren’t working well or were too hidden.
The app had some rocky beginnings, with some major timezone-related bugs that caused some users to mistrust the app and a lack of features, but we continued to improve the app and finally it became much more reliable and feature-rich. Designers are problem solvers, and because we want to hear users’ problems, it can be easy to start thinking that the app is terrible and we’re doing a bad job. I’ve found that it’s important to step back and see what we’ve achieved, so I built a small feature to get an idea of what people thought of the app, and the results were very positive overall.
The Login screen might seem like the least likely screen to change, but it’s been adjusted many times. The first major adjustment was a style change, with the ability to sign up following soon afterwards, allowing the app to become a marketing and lead-generation tool. The main cause for the stylistic change was that the gradient background proved difficult to design a form on top of, so I instead opted for a plain white sheet.
With the addition of the signup form, we caused a lot of confusion for employees. To use Tanda, staff are added to the system by their employer, and they will receive a prompt to set their login details in a welcome email, they don’t have to sign up to an account. To make this less likely to cause confusion, the button copy was made more explicit, and tabs were added to nudge employees to instead recover their password. Since this change, we’ve found that employees are far less likely to sign up for new accounts out of confusion, getting them using the app faster, and giving our sales team higher quality leads.
A final change I’d like to mention is the App store listing. After adding a signup form to the Tanda app, it became even more important to make a convincing appearance and good first impression on the App Stores via improved listing images.
With more features, it became more difficult to prioritise and order features to highlight in the listing images. With some much-needed inspiration and advice from Girish Rawat’s fantastic medium article on the same subject, I updated our app listing images.
Final Thoughts
This project has been a great opportunity to grow as a designer, I’ve learned all kinds of new skills, from product management and direction, to creating and maintaining a design system and then building it in React Native.
It can be easy to forget how much work had been done to culminate in the current app, and this retrospective was a great opportunity for me step back and see how much I’ve learned and improved.
Huge thanks as always to David Buchan-Swanson and Hugo Kawamata for building my crazy ideas, Brooke Royston for contributing fantastic designs and helping me to improve my research and interviewing skills, and all the other people that helped to make the app what it is today. 💜
