While FreeAgent helps you manage timeslips, tasks, invoices, estimates, and expenses for your projects, it’s Project Dashboards that’d finally give you a single place to share all of that with your clients, so everyone’s up to date.
Idea, research and testing, design, prototyping, HTML & CSS.
I’d long had a hunch that some of our FreeAgent customers wanted a way to share some of their account data with trusted clients, particularly things like project details. But without giving those clients their own logins and managing user permissions, that was never really possible.
The only real evidence I had for the demand was based on a few customer conversations and some forum threads, so I decided to conduct some exploratory research to get a better idea of their functional and emotional needs. I interviewed a number of customers about their client relationships, schedules, pricing methods, and common pain points, among other things. In doing so I wanted to test a number of my own assumptions:
Customers said that their long-term clients trust them, negating the need for frequent project updates. Yet further questioning revealed that shock budget moments still happen, particularly with newer clients.
Customers I spoke to wanted to track more of their time to reveal inefficiencies and allow them to estimate new work more accurately. But they saw stop/starting timers as too much of an annoyance.
There was a clear desire to get better at managing projects in general, but a reluctance to spend any extra “work time” doing so, especially if that means using an additional piece of software.
Customers who charge in day, half-day or hourly units often review their logged timeslips throughout the working week to get an idea of how much they stand to be paid for particular projects.
Retainer contracts often follow successful projects, and time is typically billed hourly based on an 8hr day. Long-term, trusting relationships with clients mean quicker payments and looser tasks over time.
Some customers record details and costs of tasks outside of FreeAgent, before eventually adding them later. By doing so, they miss the opportunity to test how accurate they are at estimating work.
After conducting the qualitative interivews, I worked with our resident data scientist to study quantitative data around engagement with the Projects feature: use of budgets, average number of tasks (including number of characters in a task name), expenses and invoices per Project. This data would form useful reference points and eventually become constraints for scale and layout decisions.
Although available at no extra cost to customers, implementing Project Dashboards would benefit the wider FreeAgent business by increasing retention among existing customers. By being the first and only feature of its kind amongst our competitors, it could also increase free trial signups and drive their conversion to paid accounts.
Informed by the research and written to guide design and development
Customers shouldn’t have to do any more than they’re already doing with the Projects feature to benefit from Project Dashboards. Let’s make better use of existing data.
If customers end up being micro-managed by clients because of the information Project Dashboards reveal, we’ve screwed up. So reveal the essentials, not everything.
Project Dashboards gives us the opportunity to experiment with new visual styles and ways of reporting data. If successful, we can then feed them back into other work.
By this point I’d written up my assumptions, user stories, suggested functionality, technical considerations and suggested metrics for success. The spec was far from done, but one of our quarterly Hack Days events was coming up, so I floated the idea of building a quick prototype.
By the end of the two days, we actually had a fully-functional proof of concept built into the app using real production accounts. Late on in the process we implemented Disqus comments too, allowing for discussion directly on the dashboards.
Evolving the visual language
Getting the proof of concept to work in two days left little time for us to expand beyond the design patterns in our existing front-end framework. But one of the project principles was to experiment with the visual language, so I spent several days over the next couple of sprints exploring new ways of displaying the data, trying to make the layout more effective and looking again at colour and type.
Dashboard data can sometimes feel siloed; the opportunity to communicate relationships and connections between the data is missed. In developing our visual language, I wanted to make sure to connect them.
Colour could imply status (‘Paid’, ‘To Be Paid’, ‘Due Now’) and be shared across different sections. Titles could help orient people around the sections, but they could also be used to report the state of their respective data, like the completeness of tasks or remaining budget. Expenses could be grouped relative to a timeline, helping to enhance the project chronology (something I later removed after it caused confusion during testing).
The trouble with too many dashboards is that hierarchy is sacrificed in the name of modularity, so they lack focus. Form, scale and layout become defined by what looks neat instead of honouring the data.
But projects in FreeAgent are extremely variable. They may or may not include: expenses, a budget, timeslips, online payment options, and any combination of paid, to-be-invoiced or due invoices. Despite this, a dashboard should never feel like it’s somehow empty or vacant. It should feel like the data couldn’t have been presented any other way, something anthropologist Carolyn Bloomer calls “optimal closure”.
By looking at production data around projects, I already knew the mean number of invoices, tasks, timeslips, expenses and more, and I knew the outlying figures. These constraints meant I could create a layout that felt bespoke, with big numbers and generous spacing, but didn’t sacrifice modularity. Having an above-average number of invoices, tasks or expenses wouldn’t throw the whole thing off.
Moving forward with the work by getting it in front of people
Feeling like I was getting somewhere with the visual language, I organised some quick guerilla testing sessions with people who weren’t at all familiar with FreeAgent or the idea of Project Dashboards. The scenario: they’d hired a design/development contractor to do some work on their company website and the contractor had emailed them a link to the Project Dashboard to keep up to date with how things were going.
I created 13 graphical mockups that mirrored typical project scenarios, then linked them together so they could be clicked through in a browser. Prior to revealing the next mockup in the series, I’d ask the participant how they’d expect the current state to change dependant on some activity (e.g. “your contractor added an expense”, “you paid an invoice”, “your contractor did some work”). I’d note down their expected changes and their reactions when the next updated mockup was revealed.
The prototype I finished up with uses the (first) mobile-first framework I built at FreeAgent, making use of a host of SASS features to speed up development time and help maintainability. It also serves up a fixed-width version of the Dashboard to older versions of Internet Explorer without any extra hacks or JavaScript polyfills.
Naturally there have been compromises, and there are a number of improvements I’d like to make. These stick out:
What did I miss? Let me know and I’ll happily add more details.
Read another case study