What I’m up to: Transfers Tool
InterVarsity’s first application put through the Product Development Process!
I typically have a ‘Where we began’ section, but what’s exciting about this project was that, for the most part, it was a project that was completely built from scratch — there was no pre-existing tool.
Purpose
InterVarsity switched over to Workday a few months ago as our HR/Finance system and our developers have been building integrations as needed. One feature Workday is currently lacking is the ability for non-accountants to request to move money around and for accountants to process those requests. The Transfers Tool was built to address that.
Discovery
Discussions had already been had about how this tool functions before I was hired, and I was given the mockup screen that resulted from the discussions.
I was also given the current spreadsheet in use. I interviewed several InterVarsity staff to gather their frustrations with the current form and to get an understanding of how the process currently works.
Accounting is Hard
One of the most difficult parts of this project was getting a mental model of how InterVarsity’s accounts work. I’ve never worked with enterprise finances before and heads up-it’s very different from your personal savings/checking account world.
I won’t go into details, but suffice it to say, there’s a lot of restrictions, money can only move in certain directions, what accounts you have access to is complicated, etc.
Prototyping/Functional Specifications
Using the mockup above, I began working through some different ideas I had.
For instance — using a two column layout for forms that need to be in a step by step process won’t work — it can be confusing to know what to fill out next if a field depends on another, which in our application would be the case.
I also thought it would be helpful to have a ‘Review’ section that updated as information was entered to provide a double check point. Even though no money is actually moved when it’s submitted, it’s easier to fix things here than after it’s been submitted.
Usability Testing
I found 3 people within the organization of various levels to put together specialized prototypes that mimicked the accounts they would actually see and asked them to fill out a transfer request form with an example that I provided.
There were a few bumps, but with several wording changes, by the last staff I tested with the form was being filled out very smoothly.
I decided to do one more test a real example starting from the home screen, rather than the form screen.
Usability Failure
Here’s where mental models are very important — in the InterVarsity’s accounting world, there are 2 types of transfers.
- Pull money from one or more accounts into one account (Called a Collect).
- Pull money from one account into one or more accounts (Called a Send).
We could have gone with a one-to-one model all the time, but this would have hindered a major use case — pulling the same amount from 50+ staff accounts for a staff conference fee, for example.
That’s the beauty of digital versus the paper spreadsheet in use before.
So in my test when I asked the question “Where would you begin to start your transfer”, my staff that had a one-to-one transfer in mind was completely lost with the UI above. While I knew that either one would have been fine, she didn’t know what to pick.
So, we went back to the drawing board and decided to eliminate the choice of ‘Send’ and ‘Collect’ to what staff were more familiar with — let ‘Send’ and ‘Collect’ be determined by the Transfer they were trying to make, rather than the reverse.
This UI was more smooth, especially after I conducted a few card sorts to find an organization strategy that resonated with staff.
When the prototypes were in a state that I felt reasonably confident that we were on the right path, I annotated them and built functional specifications to outline how the tool worked.
Design
We have a basic Style Guide at InterVarsity, so building out the design was taking our Style Guide and applying it, plus building out various screen states. so that developers wouldn’t have to repeatedly walk through steps in a prototype to get to the various states.
Usability testing & Job Aid after Development
There are always things that testing after development will catch that testing with a prototype won’t catch.
For instance, one thing you won’t be able to find in a prototype is catching all sorts of validation error s— we had a strange problem where a comma was being treated like a decimal point.
Test, test, test. Then you should probably test again.
Launch
We did a soft launch with just accountants in late September, and then did a full launch October 9th, 2017.
There’s actually a whole second side to this application — what happens when the request is made. To keep things short I won’t go into that level of detail, but suffice to say, accountants have a hard job and I don’t envy them :)
Learnings
Looking back, there are a few things I would have liked to have done differently.
More Explicit Use Cases
A few weeks post-launch, there are use cases coming up that I was unaware of. I’m reminded of this article and I should have spent WAY more time talking with our staff on how they do transfers. One advantage Excel has over what I designed was the ability to drag down a value through a whole column — I severely underestimated how important that was because of my own assumption — not because I talked with a user.
Documenting Decisions and Changes
One of the major ones was how to documenting decisions and developing a business requirements document. I would document changes in the functional specifications so that my developers would would know what to build, but there was no higher level living document. That would have alleviated repeated conversations about was or wasn’t happening with anyone that wasn’t a developer. (PS, I wrote about documenting changes with developers and am still looking for thoughts!)
A more detailed launch plan
The launch was not as smooth as I would have liked, due to a lot of unfortunate circumstances — people out of the office, last minute bugs found, etc. It could have gone a little better if the launch plan had been detailed to at least the hour and if we had implemented a code freeze earlier.
Results
Generally, digital launches like this have not gone well and staff are wary of what National InterVarsity produces. A few months following the launch, we’ve been hearing great responses to the Transfer Tool.
“That Transfer Tool has been amazing for my area — we found money we didn’t know we had in some accounts, we were able to zero out some accounts that had negative balances and really understand where our money was.”
Props to Ashley on the design and building of the transfer tool. I had heard it was great from others, but was so skeptical that I still procrastinated until June 29 to do 6 months worth of transfers for my old team. But when I actually did it, it was so easy, it took me about 15 minutes to do what I had budgeted a full hour to do. And it was even- FUN! =)
Thanks
This was a hugely complicated tool to build, and I am so grateful that I didn’t have to build it! So a big round of congratulations to Nathan Lenz and Paul Utley who developed it; they handled far more than I probably even realize.
A big thanks to the many staff who gave input on usability tests — so many improvements were due to your voice, and I know it isn’t part of your job, so thanks for taking time out of your day.
Many thanks also to Accounting for being patient with me as I tried to wrap my head around the mental models of how accounts work — and thanks for keeping our finances running.
Ashley Crutcher is a Digital Designer at InterVarsity located in Madison, WI. She tweets at @ashleyspixels and enjoys cuddling with her cat, crafting, working out, and thinking too much about everything.
