App a Week #1 – Some thoughts on process

I finished my first app for App a Week this week. Here are a few reflections…

Code first design later

I really have two competing aims with my App a Week challenge. One is to force myself quickly iterate and develop new apps and hence practice idea generation, rapid prototyping, and app design skills. The other is to learn how to develop apps using objective-c and Xcode. These competing goals, combined with time constraints, posed a bit of a problem.

I didn’t have time for a “good” iterative design process:

Instead, I found myself operating using what is usually considered a “bad” process:

Why is this bad? Because it’s inefficient. It is much better to test the designs and iterate through problems with design and usability well before you start coding, because implementation is complicated, and changing a paper design is far easier than changing a functional piece of code. I would have loved to test everything using lo-fi paper prototypes, briefs, photoshop files… but I had to code the thing, and I had to make sure I could code the thing.

I don’t yet know exactly what I’m capable of building.

So I programmed and designed in parallel. In fact my paper “designs” never got past this sketch level of fidelity. I found myself sketching up a a few screens, building partial, or even full functionality straight in Xcode, and testing it as a functional app.

The advantage of this was that I got a lot of coding practice in. When I ran in to design issues I had to solve them programatically (I originally used a modal view for creating new categories, but after testing realised that this interrupted the workflow too much and changed the design to use a navigation controller push) and had to refactor the code immediately – and learned a lot more in the process.

There was pushback too: when I realised I didn’t have time to make a custom keyboard for price input, I had to change the design to split the price input fields in to dollars and cents – not ideal, but not a bad functional trade-off.

I think App a Week will be a constant struggle between these two competing goals – it will be interesting to see where this takes me.

The power of structures

One design decision I made out of expediency was a simplified workflow – originally I had wanted to be able to add transactions from the home screen (the app as it stands makes you choose a category first). This would have been more complex programatically – with all transactions going in to a default “uncategorised” set, and the ability to reassign categories – and when designing the object model I ditched the idea.

This actually improved the app. Because there is no identifying data with any transaction except the date (in order to make transactions simple), assigning categories after the fact would rely on the user’s memory – I spent this much, but on what? – something I wanted to avoid. It also reduced the number of screens required (there is no “transaction category assignment” screen). And because there is only one way to create transactions, you only have to learn one behaviour.

In fact, because the app forces you to select your category first, it suggests that you must add all the relevant information to the app in a single exchange or risk losing the information – increasing awareness of the transaction. This structural limitation which I decided on for the sake of expediency just happened to align with my goal for the app: to force me to pay more attention to my spending.

This is certainly something that I want to delve in to further – how does the flow of the application affect how the user thinks about the task he/she is performing? When designing an application, how do you want the user to think about their actions?

Can an app be designed so that the structure of it helps to change a user’s behaviour, rather than just helping them complete a task?