Pierre Roberge

UX Product Designer

I helped Accountants collaborate better with their clients

Wolters Kluwer : Canada - USA - New Zealand - India

Project Goals

The first goal of the project was to establish a grand vision for a Cloud-based Document Management System (DMS) to be integrated into iFirm, an accounting firm management system.

The second goal was to create the detailed specifications for the development team for the version 1 of the DMS.

My Role

I created both the long term vision (features and experience) and the detailed specifications for this new product. I made sure the needs of both the North American and Asia Pacific regions were met. The specifications included the detailed screens for the developers and I was the owner for all product related questions during development.

Interviews

Stakeholders Interviews

In order to understand the parameters of the project, I conducted interviews with many stakeholders including : executives, product managers and developers from the 2 regions in order to understand the business, technical goals and constraints.

Questions I typically ask during stakeholders interviews are:

What is the business motivation for this project?
What is the positioning of the competitors?
What will success look like for this project?
What are the contraints : time, budget, technical, ...?
What are the potential pitfalls I might encounter?

Characteristics of accounting firms visited

Potential Client and User interviews

In order to understand how accountants work and interact with their clients, I conducted client and user interviews with accounting firm partners and their employees both in Canada and in the US. 11 small and medium-sized firms were visited to understand who they were and obviously how they worked with their clients.
My goal was to get to know these people on a personal level to some extent before understanding how they worked.
Questions I typically asked were:
Why did you choose to become an accountant?
Where did you work before?
What made you decide to start your own firm?
Describe a typical day.
What do you enjoy most/less in your work?
What do you consider is a good day at the office?
What are the types of mandates do you typically do?
Where are your clients located?
How is the relationship with your clients?
How do you currently exchanged documents internally and externally?
...

Insights

Example of an insight discovered during client interviews

What are the problems we needed to solve?

The interviews made it clear that accountants have other problems to solve in addition to the digital storage of documents. Here are some examples, I uncovered:

better manage the collaboration with their clients throughout a mandate

help clients bring all documents required, on-time
collect documents from clients more frequently throughout the year without getting involved personally
efficiently exchange with clients for missing information

work with digitized documents as easily as with paper
efficiently act as a secure client storage repository when clients need archived copies of statements or tax returns

A good DMS would need to solve these problems if it is going to be adopted.

Primary persona I discovered during the interviews

Personas

By speaking with partners and employees made it very clear that there were several personas that we needed to please for this project.

The 2 most important personas were :

- Paul, founder of his 5-person firm, who prefers working on paper and only digitizes paper after all his work is done for archival purpose.

- Stephan, sole proprietor of his 1-person shop who loves technology and will use technology even if it makes him less efficient at times. He digitizes everything before doing any work.

Paul was deemed our primary persona because he has zero tolerance to badly design technology and will be hardest to win over to the DMS. If we design a solution easy enough for Paul, Stephan, our secondary person, will also be very happy.

Product Vision

List of all the functions a good DMS needs to have to solve all problems discovered

Design Imperatives

I came up with the Product Strategy detailing how our DMS system will be able to satisfy accounting firms

Some examples of those needs are :

help CPAs collect all the right documents on-time and provide a trace all exchanges.
help CPAs collaborate with clients while working on a mandate.

Sketching features

Description of the behavior and sketch of one of the features

Designing the behavior

Using the power of scenarios, I roled-played each persona to put myself in their day-to-day shoes and came up with features that would please them. I described each features functions, behavior, look, and how it satisfied a specific problem or fulfilled a need.

For example, to facilitate the communication and the shared responsibility between Paul and his or her client, I created a shared action-oriented To-do list. The list is created by Paul and describes what is needed from his client. Paul works in a "help me held you" type of relationship. Having a shared To-do list is a great way for Paul to describe what each party's responsibilities are and are also a way to indicate when they have been accomplished for the work to resume promptly.

The salient design aspect of this To-do list is that it is action oriented. Every item starts with a verb (depicted as a clickable button) in order to make it clear to the client what he/she needs to do but also to help the accountant learn about this tool and start thinking in terms of clear specific actions that are required. Just having free-text list items would have required more training and support to the accountant in order for him/her to reap the benefits of this feature.

To help clients decide what they have time to do now, I show, in parenthesis, the expected time to completion for each action.

As the client performs each tasks, by clicking on the green action button and performing the specific action, the task is automatically marked as completed and Paul receives a notification allowing him to continue working on the mandate right away.

Final screens

High-fidelity screen I sketched for the developers

Final Screens to developers

Once all the features have been sketched in terms of behavior and look, validations tests were conducted with all stakeholders and potential clients. The features were tweaked based on feedback and also prioritized in terms of client value and time required to develop.

Screens were very helpful during the scoping of the project in phases. It is a lot easier to get people on the same page using screens.

I then wrote the specifications for Phase 1 and 2 of the project and produced the high-fidelity screens using the current system color palette, sometimes working with a graphic designer to make sure things looked pretty and used the same look and feel as the host application.