Extending expense reporting on mobile

The Visma.net Expense platform recently reached a milestone before the summer vacation, when Visma Employee launched it’s 5.0 version allowing expense claims to be sent from the phone.

With the ever growing library of apps and the spreading of services (both private and public sector) to phones, the demand for extending our own Visma services has been there for a few years. Here is a glimpse of the work that has been done on the Visma.net Expense platform to date, and some reflections on what has worked well (and not so well).

When planning the functionality to be made available on the phone, the work was intentionally divided into distinct steps so that releases could come more frequently, allowing earlier feedback and smaller releases. Agile, instead of waterfall. The plan was originally in three tiers. First: only viewing your existing claims. Second: using the Attach app to input receipts that the Employee app would display and allow users to select, edit and send. Third: calling on (or embedding) Attach so that all steps of adding a receipt could be handled from Employee. This plan was slightly modified as design for the screens progressed, as it was deemed that users would not want to input the more advanced receipts and would be satisfied with performing the simplest of flows. As of September 2018, the mobile plan for Expense is now a 5 step process where step 3 is ongoing.

The 5 step process.

Lessons learned from the release plans

Frequent releases are good, as we have quickly been able to adjust minor issues that presented themselves and also gotten feedback on the product to date. What was less good was the assumption that users would settle for only a subset of the functionality from Expense, simply because the screen is smaller. Rather than hold back on what flows users can complete, the mobile version should focus on keeping the manual input to a minimum and allowing users to view, confirm and send their content. Provide the same flows, but make them easier to complete.

In the mobile version it is the presence of receipts that drive the creation of a claim, as opposed to the web version of Expense where users are asked to first input claim information before adding content. The reason for this flip in process is driven by the pairing of Employee with the popular app Attach. If users have previously added receipts in Attach that are waiting to be sent, the receipts are made visible (as a bottom nav or a badge) and so trigger the process. This is not the case in web Expense, as users can there add other items (like images / pdf:s or a trip or mileages) and so there is not the same given trigger.


Android bottom navigation.

iOS toast for receipts.

Lesson learned by this process flip

As the mobile has limited screen space and less integrations with other services, it forces the process down to the single most popular feature, in this case adding receipts. Making the input the driver of the action reflects the real world process for the user. Even when the mobile application will expand to more functions, keeping this mindset should improve the experience. And the same lessons could be taken and applied to the web version as well. Let the real world triggers be the same triggers in the flow.

The mobile flow of starting from receipts and later adding claim information also revealed a different issue. The mobile flow focuses on the content (all the receipts you can send) as well as the context (you can add these receipts to any non-sent claim or make a new one) in a way that the web version does not (users start by creating a new claim). Early feedback from the first real users trying this flow revealed that old content such old receipts and old claims suddenly came up to the surface. We did not anticipate that users would have so much old content clogging up our nice new flows.

Lessons learned from surfacing all content

When designing flows, it’s easy to get lost in utopic scenarios where users only have the exact content that fits nicely in your designs. (Even after many years of design work, this is easy to forget!) While we may be making simple flows (select receipts and just send), we also have to give users the tools to clean up the content. In our case, it means allowing users to remove old claims and receipts that they do not wish to use, and editing those receipts that need some extra information.

There will be more lessons to be learned from moving functions from regular web to mobile and as we continue to get user feedback from future releases.