Designing Rosters in the Tanda Mobile App
In January 2017, I started my paid summer internship at Tanda. Our task was to design and build the Tanda Mobile App — a pretty daunting task for someone fresh out of uni.
Two years and a lot of lessons learned later, we’ve hit 25,000 unique weekly users, made up of 11,000 unique people that use our app every single day. It’s been a bit bumpy at times but I’m proud of what our team has built. This post is a retrospective look at the most-used page in our app — the Work tab — which allows employees to view their work schedule.
The internship
My introduction to Tanda was my Summer Internship. I worked with a team of interns with the goal of making an MVP for the mobile app in 5 weeks. This ended up being a struggle as I spent a lot of my time learning React, learning what Tanda does and what our customers want from us.
… That design makes me cringe in hindsight, but I’m also proud of how far I’ve come as a designer. A lot of design decisions I made were uneducated assumptions. For example, Tanda has four levels of splitting the work employees do: Shift detail, team, location, and organisation. The design above only worked with three of these. The others are not shown in the screenshot above, but here’s how the design was structured:
🤦 There are a lot of issues here:
- There is pretty much no information hierarchy whatsoever.
- The shift time has no title for some reason and the vertical alignment is different to the Location.
- All four levels are named by the customer with a text field that has no character limit. What if a client has a really long name for any of these? Does the text wrap or does it truncate?
- Tanda allows breaks on shifts. You can have an automatic break, or breaks at specific times. You can have any number of breaks.
- If an employee works at multiple organisations, where would we display the organisation name?
- The team colour doesn’t really look like it’s related to the team. An employee might misinterpret the purpose and meaning of the colour.
What I learned: Don’t make assumptions, ask questions. Unfounded assumptions are how you design yourself into a corner. There was always someone close by that would have known the answer to any of these questions, all I had to do was ask.
Starting over
Over those six months, we agreed that the work done on my internship was a great learning experience, but it would be more beneficial to start fresh with my improved skill and better knowledge of our product and client base.
Aside: We also decided to build the app in React Native instead of React with a Cordova wrapper, which is how we built the internship project. As a designer, I love working with React Native. Check out Kelvin’s article for a designer’s perspective on React Native.
With my new knowledge, I went back to the drawing board:
Again, these aren’t great designs, but they’re a big improvement. At this point, I had a nasty habit of designing by myself in Sketch and trying to make everything pixel-perfect before asking for opinions and criticism. I eventually learned that the best designs come from collaborating with other designers. Instead of jumping into Sketch, we went over to a whiteboard and talked it through. This, in my opinion, improved the quality of my work substantially.
What I learned: Try as many different ideas as possible. The first thing that pops into your head is never the best. Iterate on what you like, if it doesn’t work, start over. Working in a product company is a team effort, you don’t get extra points for doing things solo.
Who are we designing for?
If you look at the last four designs, you’ll notice that the information we’re showing is slightly different every time. Sometimes there’s hours, and wage earned, sometimes there’s clock in photos. Again, I was making assumptions about what information employees wanted to see when they checked their schedule. I’m designing this product for real people, what do they want?
So why don’t we just ask them? At this point at Tanda, the only reliable method we had for communicating with employees was their roster email (This problem has since improved by employees adopting the app).
So I made a Google Form, and put a link in the bottom of every roster email.
The results of the survey had me surprised. I’d again been making a few poor assumptions. The majority of people did not want to see their clock in photos. I’d been designing them into almost all of my latest iterations. Employees also really wanted to see the length of the shift in hours — something I’d only added to a few designs. I thought it was interesting how many people answered team and location as neutral or not important, but I’ve chalked this up to these employees working in the same team or location, making the shift team and location redundant to them.
What I learned: Don’t just test assumptions internally, ask the people you’re designing the product for. Do this early, if the product doesn’t work for them, the product won’t be used, and that’s a lot of time and money wasted.
Back to the drawing board
With the knowledge from the surveys, I iterated more, until we found something we were happy with.
And there you have it, we’re done. Build it and ship it! Wait…
It didn’t take long to work out what the issue was. The information hierarchy was a little off. With a little adjustment, we ended up with the following.
The design on the right is what we ended up shipping in the first public version of the app in December 2017. Aside from some minor tweaks, they’ve remained much the same for almost an entire year.
Just because it’s live doesn’t mean it’s done
In the very early days of the app, I was frustrated that there was no way for employees to give us feedback. We tried sending a few Google Forms, but they weren’t very successful, so I took an hour out of my day to build a Feedback form into the app. On submission, the form sent a webhook to Zapier, where a zap then added the feedback to a spreadsheet. It took minimal effort, and the form has been invaluable ever since. Over the year, we’ve received 800 pieces of feedback from our users.
The beauty of working in a product company is we constantly revisit features and iterate. From in-app feedback and our user testing, we’ve made many adjustments to the Work screen. The most notable of which was removing infinite scroll (Notice the weeks above are separated with a grey line) and instead split each week into its own screen.
The update to the Work tab was designed by Brooke Royston. Before releasing this update, we had received a lot of feedback that the roster was difficult to read and navigate. Since removing infinite scroll, we haven’t received any negative feedback about this screen.
What I learned: Nothing we ship is ever truly finished, never wait for a design to be perfect before shipping. Feedback forms are extremely valuable and every app should have one, the insight we get from something I built in an hour using Zapier has paid for itself many, many times over.
