Go hard and go home: what it’s like designing during a pandemic
1 design problem. 2 designers. 3 days.
At the end of April 2020, the Australian Government introduced a range of measures to help small businesses deal with the impact of COVID-19. JobKeeper was one of those measures. It was basically a flat rate payment of $1500 per fortnight for each employee, so businesses could keep paying their staff.
As a product designer at Xero (a cloud-based accounting software service), I spend my days designing compliance products in the sales tax space, where businesses report numbers to the government. So I was at the coalface of the JobKeeper initiative, which was terrifying given I’d only been at Xero for about six months. We have a little joke for new starters in the Xero design team — give yourself six months before you feel you can confidently make a decision. I was about to find out if it was true!
Our task was to help businesses pull together the numbers they needed to provide the Australian Taxation Office (ATO). That meant building something new, which people around the country would depend on, with the knowledge that getting it wrong would be disastrous. And did I mention that we were all working from home? The pressure was intense and some parts are still a little hazy. But here’s how it all went down and what I learned along the way. This is a designer’s perspective.
Project kick off
As soon as JobKeeper was announced, we pulled together a group of 14 volunteers from two development pods and got to work (it was hard for some people to volunteer for the project, especially if they had kids with them in lockdown). We started by looking at what we knew about JobKeeper, which wasn’t much. There wasn’t any information yet — the legislation hadn’t even been written.
All we knew was that JobKeeper would be offered to businesses that could show a 30% fall in revenue from the same month in 2019, and some dates from the ATO that we had to align to.
In the kickoff meeting, we talked about the requirements, the people affected by the problem, what tech we could use, and what we as a team needed to do to hit deadlines. The timing meant we needed to phase our work and concentrate on the most important tasks. We agreed as a team that we had four phases, which became problem statements to work towards:
- How might we help customers with their enrolment calculation by 20 April
- How might we help customers support monthly reporting by 29 April
- How might we help customers support enrolment and report for more periods by 1 May
- How might we support customers with ongoing reporting obligations
So it looked like we needed a way to calculate and determine eligibility, along with a way for our customers to report their monthly business turnover moving forward. The deadline was incredibly tight — we would need to design the calculator in three days and the monthly business turnover tool in another 10 days, aligning to the government public releases.
We’d been sent home four weeks earlier due to COVID-19, so we had to do it all remotely. I’m used to working remotely, but for most of the team it was a new experience. Luckily as a global company, we were already set up with cloud collaboration tools like Figma, Miro, and Google Suite.
Collaboration
Design is a team sport and within 90 minutes of the kickoff meeting, we ran an initial one-hour ideas workshop with product and engineering, using Miro to get everyone on the same page about who we were building for and a direction to start working towards. A simple question was posed: How might we show a year on year fall in turnover? From this, we came up with 10 ideas for myself and the other designer on the team to explore. We rapidly prototyped concepts in Figma, looping in the product managers to assess their viability and the engineers to assess their feasibility.
Bringing other disciplines on board early in the process was vital. We simply didn’t have time to do a lengthy discovery process — we needed to quickly determine whether the idea had merit and whether it would be valuable to customers. The solution also needed to align to the application date and reporting dates that the ATO had set. So we used the MoSCoW method — otherwise known as ‘must, should, could, would’ — to sift through our ideas. It’s a way to rank ideas and work out which ones should progress and which ones need to be discarded:
- M = MUST have this requirement to meet the business/customer needs
- S = SHOULD have this requirement if possible, but project success does not rely on it
- C = COULD have this requirement if it does not affect anything else on the project
- W= Would like to have this requirement later, but delivery won’t be this time
This kind of close-knit collaboration meant there were no magician moments in terms of design. You know, when a designer spends an inordinate amount of time alone and comes back with THE design, replete with a ‘ta-da’ reveal. It doesn’t work most of the time and we wanted to make sure it definitely didn’t happen with this project. Using the knowledge of the team meant we could make fast decisions, without any second guessing or going off track. Everyone wanted to do a great job, so it was important that we all worked closely together (even while physically apart).
Our design approach
Design is as much about what you don’t put on the page, as it is what ends up there. Sounds simple, but it’s one of the hardest things to achieve, because it means you need to get the design out of the way and let the customer do what they need to do. After all, it’s their product, not yours. This ‘just enough’ mindset of not putting too much (or too little) information in front of the customer was even more important with this project. We knew small businesses had a lot to deal with — from closing up shop to dealing with staff and homeschooling kids, so it needed to be simple and effective.
Other teams in Xero were also building tools in response to JobKeeper, so we needed to align the customer experience. If someone was using our work to test eligibility, they may also use the Payroll products other teams were building to pay staff. We needed to ensure a seamless transition between the two parts of the product. Collaboration sessions with the designers on that team helped to ensure consistency.
To save time, we tried not to reinvent the wheel. We used existing design patterns and components from our design system, XUI, to build the calculator and supporting pages. We used standard form fields instead of custom building. We did desk research and checked out other calculators for patterns and inspiration — like the ones on bank websites to determine eligibility for home loans. This made sure we were giving customers an experience they may already be used to, so it was faster to design and easier to use. We always keep the customer in mind when solving problems, but the lack of time meant we had to use our instincts a lot of the time when making decisions, so that empathy was even more important.
Iterating on the design
Because we were designing and building a product in a world of unknowns, iteration was our best friend. In tech, nothing is ever done and nothing is ever perfect, and we’re constantly learning. So it’s about looking for opportunities to iterate and improve the work to make it simpler, clearer, or just plain old better for customers. For this project, we designed knowing that the scope may change once the government had legislated JobKeeper and businesses started applying for the program. Designers are used to dealing with uncertainty — we are change agents — but we were conscious that developers often need a firmer foundation.
Once we had a few options prototyped, we shared it around with other designers for some fast critiques based on a simple question: ‘does this make sense to you?’. We also got feedback from some trusted Xero partners about their concerns and what information they needed to determine eligibility for JobKeeper. Having experts in the process helped remove risk. We learned so much from this — considering how extensive our usual research process is, it gave us the information we needed to iterate with confidence. We started on Wednesday, asked for feedback over the weekend, and made the changes Monday morning. Then after releasing, we monitored social media and comments on Xero Partner channels and kept on iterating.
Releasing the JobKeeper calculator into the wild
Most of the design work was completed in three days, including a design quality assurance check while it was being built to make sure the design was reflected in the engineering work. This really drove home to us the importance of working with engineering at every stage of the process — nothing we do should ever be about design sitting alone in a corner of the room. What engineers build is what the customer sees, and we respect that. I think the engineers really appreciated our input too, as it meant a better product at the end of the day. We also built a strong rapport with the whole team, which was helpful to make sure nothing got missed while we were moving at speed.
Other teams supported us to get this work done, and it would be unfair to not mention them here. Content writers reviewing words on a Friday night, other designers giving instant feedback and riffing on ideas, product owners offering support, and engineering teams doing requests. Others were simply asking, ‘are you ok?’ and ‘is there anything I can do to help?’ Support was felt and this work was truly a collaborative effort. Our existing team members that did not directly participate in the JobKeeper work needed to pick up the slack in our BAU work, and without them we couldn’t drop what we were working on and start this vital piece of new customer work. So, thank you team for having our backs!
One week after starting the project, we had a working feature that small businesses could use to calculate their JobKeeper eligibility and report monthly business turnover. Looking back now, I’m pretty happy with how it all turned out. Yes, we could have done more or built it differently. But given the timeframe and the amount of information we had, I think we built a strong foundation for future JobKeeper releases. And I’m proud of the team and everyone who helped us get it across the line.
Eight months ago, I came to Xero so I could spend my days doing work that matters. It’s certainly not business as usual right now — but doing work like this makes it all worthwhile.
