The financial web application that I have in mind is relatively simple in concept, but contains some interesting design challenges that I want to explore here.

The elevator pitch is simple: the app lets you copy-and-paste your financial transactions (in whatever format your bank uses), categorising and correcting as you go; you can then build custom reports based on date intervals, categories, amounts, or any other attribute, and save them to a permanent dashboard.

This two-pronged feature set — input and output — suggests two primary interfaces:

  1. Importing. A blank canvas into which the user pastes their transaction data. The app converts this into a clean list of transactions, auto-categorises any it recognises, and presents the remainder for review and categorisation (including the possibility of creating new categories).
  2. Reporting. A set of tools with which to manipulate the transaction data (category filters, date range selectors, account selection) paired with a table of transaction data and graphs of various types (as chosen by the user). Reports can also be named and saved.

Tying these two together, the user’s dashboard presents a list of the saved reports — with name, date range, or other identifying information — for easy access, together with two primary actions, “Import Data” and “Create New Report.” There will also be a secondary set of account-related information, allowing the user to add, remove or update their bank account details.

Since my initial impulse is to approach the design of the project “Mobile First,” the first decision is which functionality to include on the mobile platform. Clearly copy-pasting large chunks of table-based data is not going to be an easy task on a phone, and since I only envisage needing to perform that action around once a month, it’s an easy decision to drop the entire importing interface from the mobile version of the app.

What about report creation? There probably won’t be enough screen real-estate for tweaking settings and checking the results in a single viewport; and again, I don’t envisage needing to create new reports all that frequently. We’ll drop that from mobile too.

That leaves the dashboard with its list of available reports, and the individual report views. Each report is a coherent unique item, with multiple attributes — at least a name, and possibly other metadata like date range, last update, that sort of thing. I’m leaning towards a card-based, Material Design-ish kind of idea here, with a fully-clickable, almost full-screen card per report. Selecting an individual report would load that data, although what is presented may be a slimmed-down version of the full desktop experience.

I think perhaps the first thing to do is to identify some likely report types and then to start sketching the presentation interface for the data involved, and see what emerges.

Incidentally, I read an interesting article today on the Invision blog on Why You Should Write Your Interface First. In it, Tinder’s Scott Hurff discusses how many designers will begin a project in plain text, by writing out the interface elements needed and thinking about the words they will use in the interface’s conversation with the customer.

I almost always start a new project with a Google Doc nowadays; perhaps that’s a good sign.