Booky Accounting
Booky is an app for mobile and web offering accounting solutions for small to medium sized businesses.
Kicking off
The founder of Booky had been a product manager of multiple accountancy products before starting up. To make use of this knowledge we had a kick off workshop along with a former accountant-turned-consultant, the teams business analysts, marketing, design and tech.
Our intent here was to dig deeper into the painful issues with accounting in general and what frustrations businesses face in using existing software.
We started off with the Google Design sprints “Ask the experts”. We were talked through exactly the types of tasks people were trying to achieve and our former accountant presented us what types of queries made up most of the phone calls to his office.
From notes and examples, I asked the room to jot down three key pain points they had discovered this far in the workshop. From here we grouped those that had similar meaning and labelled it with the overriding theme. Now looking at this we’re able to prioritise focus and set a solid problem statement.
Ideas time
With a clear problem statement plastered on the wall in full view, the room was now enabled to start ideating with potential solutions in mind. To get the ball rolling we went through all the participants “homework” in the room. This was to present an example of a digital product that they personally liked, something that was seamless to use and solved their problems.
This is the point where participant’s creative juices should be flowing. A “crazy 8’s session followed by the individual’s solution sketch. These sketches were voted on by all fellow sprint members based on which best responded to our problem statement. We took three very different concepts forward.
Concepts to prototypes
Armed with three concepts to take forward we needed tasks to mould the concepts on. We took some time to sit with our former accountant to block out and card sort all major jobs this software would be able to deliver.
From here we selected three major tasks and made a task-flow to take our concepts to. A user wants to view something, a user wants to pay for something, a user wants to do something.
Testing
We done some very low level guérilla testing of some refined paper wireframes around the building to gauge initial reaction, feasibility and feedback to bare in mind when building the clickable prototypes. We made some quick-win adjustments from here, simple things such as titles, field placement, larger layout.
Clickable prototypes were made low fidelity for fast turnaround and to keep neutrality before any visuals had been looked at.
Test day. We looked at three different concepts to try and perform three different tasks with six different participants.
In observation it stated what overall we wanted to test in direct response to our problem statement. With the users tasks at focus and the “happy path” detailed in step-by-step check boxes. To measure this we would like pass rate, obstacles, time taken to complete and overall user satisfaction.
At the end of the day there was very clear fails and we could almost ditch entire concepts based on some of the painful sessions we observed. Looking at the other findings, we had some certainty in what to develop further.
Refinement
From our test report, we took some of the prototype’s big wins to put together into one solution. We developed this for another round of testing. We kept our initial test tasks from the first round and added some extras to see what else we could find out.
Not without its pain-points to be worked on, the insights validated a lot of our amendments. We felt strong enough in our position to start to look at the visual treatment on the software that was starting to come together.
Visual design
In our half day session, I started by giving a hand out getting the team to give me three individual adjectives they’d want the product to convey visually.
After this I put up a psychology colour chart for their reference to take a look at and fill in their handout about what colour they felt best suited their chosen adjectives
A few days prior asked the team to send examples of visuals they like relevant to the product. I put them all together in a large wall piece for us to explore together.
This session was not to get a shared interface vision but to get takeaways on brand principles and wants in open discussion around activities. Again, all with the problem statement in plain view.
Building the interface
I made high fidelity colourless wireframes where lay out, padding and proximity was set. I used the notes taken from the visual design session to assist me in creative the visual language for Booky. I would show progress in screen context and within singular components explaining certain design decisions made for colour, font, shape,
line and hierarchy.
Final screens
I developed interface designs based on brand principles, feedback from test findings and workshop observations within the tight architecture and confined task categorisation and the of the app.
Colours are bold highlighting important information and call-to-actions, a secondary and tertiary style has been carefully considered. With limited time I created core screens with custom icons and presented the contents as individual components. I broke down how where and when these components can and should be re-used with a style guide to take forward.
What now?
Booky has key journeys prototyped with remaining journeys documented including flows, style guides and component library. These key journeys are in development for the team to launch the MVP to trial further before launch.