projects August 11, 2016

Add It Up: Initial concept, mobile scope 


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.

projects August 06, 2016

Let's Add It Up 


At, we don't just develop software. Figuring out how to develop our people -- specifically, our designers -- is one of the fun things I sometimes get to work on. And, naturally, part of that is figuring out how to develop myself as well.

One of the ways in which we encourage our designers to improve or increase their skillset is through peer-to-peer (P2P) learning, where groups of half-a-dozen or so designers form a team to undertake a project on which they can develop a particular skill. This encompasses both 'soft' skills such as mobile design, icon design, or colour theory; technical skills like JavaScript; and proficiency with design-based programs like Sketch and Framer. Groups meet regularly over the course of several weeks, helping each other with their individual learning goals and producing a product at the end of the process to which they have all contributed their time and energy. It provides an opportunity to exercise skills that are either not needed during normal day-to-day work, or that they wish to focus on improving as part of their own career development.

Unfortunately, for remote workers (as I am), it can be hard to participate in this kind of group process. Scheduling meetings is hard enough in a busy company; accommodating one person's travel schedule is next to impossible. And Skype or other online options, while useful, do not come close to allowing true collaboration within a group setting.

I decided to pursue a solo option.

Personal development time

Way back around the dawn of the modern internet, when blogging seemed like it mattered and everyone thought they could be the next Zuckerberg, I decided I was going to create a financial management web app. There were a few services around already; Mint was probably the most successful back then (they're still going today, albeit as a shitty-looking Intuit company -- their promising competitor, Wesabe, folded in 2010), but I wanted something that did exactly what I needed. My dream service would allow me to quickly import the financial transactions from my technically-challenged, export-free bank via the magic of copy-and-paste combined with regular expressions, and produce wondrous graphs and reports to allow me to monitor the ups and downs of our family spending and saving.

Back then, I was more interested in the backend technical implementation details than the design or user experience, and I wrote a handful of blog posts discussing the challenges of ORM and URL naming schemes. Sadly, the project never progressed further than the virtual drawing board, but it has been in the back of my mind ever since, so when I began to consider candidates for a solo P2P project, it was clear what the favourite option was likely to be.

So far I have drawn up a brief summary of functionality, and a shortlist of the technologies and disciplines that I want to either learn or improve at using:

  • RESTful API design - I've done this before, but I'm not really sure I've ever done it entirely right;
  • Facebook's React.js - one of the current hot JS-based technologies that I've not really dug into yet;
  • Build tools such as Grunt or Gulp;
  • SVG icons - the modern standard that I should really learn about instead of being stuck back in the sprite stone age;
  • Sass - I've used this in the past a little, but there is little opportunity to use it on a regular basis at work;
  • Client-side caching with LocalStorage, and possibly app caching.

These primarily technical choices are in addition to the obvious need for UX/interaction design, decisions about colour, and probably a need to design a logomark at some point. I'll be posting occasional updates here, and screenshots to Dribbble as the project progresses.

The only part of my earlier project to remain the same is the name. Besides being a great Violent Femmes track, Add It Up still seems to me to be a splendid name for a finance tracking web app.