I am currently redesigning Buffer, an iPhone app for scheduling tweets without having to think too much. In the first part we got the ball rolling and looked at the overall process of app design. Now it’s time to get down to some real work.
Before rushing into the wire framing process
, it’s a good idea to create a flow diagram of your proposed app to get an idea of what it’s primary functions will be. A flow diagram gives an outline plan of the whole app, helps identify any problems which need to be solved and starts to give an indication of the structure.
The flow diagram is just a set of boxes indicating possible screens and processes that need to be considered somewhere within the app.
You don’t need any special software to do this, a sketch on paper is fine – the ideas and content are what really matter. I used Axure as its a tool I use a lot and it happens to have flow diagram tools and lines that automatically join them together.
Usual flow diagram components were used to map out the process of posing questions and user journeys that the app would ask and follow. The flow diagram in this case highlighted that there were some problems to solve, especially with the signup process.
Starting to Wireframe
So now we there was a plan to work from and the process of drawing up wireframes could begin.
Normally I wireframe in Axure, which would have been perfectly fine for this project too, as Axure has some fine iOS interface libraries such as those from Axutopia.
But I decided it would be fitting and rather cool to use an iPad app for design work. Yes, I love my iPad dearly for consumption, but it’s very rarely found a use in any kind of production work. So, basically I try to find an excuse to use it whenever I can.
My first wireframes used a very nice iPad wireframing tool I happened to have, iMockups, and looked like this:
What I soon realised was that even though iMockups is a great ‘sketching’ tool, it wasn’t locked down enough for me as a newbie iOS app designer. I found myself drawing components at arbitrary sizes and making decisions based on bad information. Yes, it’s ‘just a wireframe’ – but if it feels like there isn’t enough space for something to happen in the limited space available you can find yourself trying to make fundamental decisions simply because you don’t have an accurate indication of sizes.
For example, I drew an account avatar and it looked fine. But I assumed that an avatar icon in the app header would not be large enough or visible enough to determine the account being used. Looking back at various iPhone apps I realised that this is simply not true. A long time user of Beejive I realised that the Avatar of the person you were talking with was always shown top right in the header bar and it was extremely useful.
Bluprint is a very cool package, specifically aimed at wireframing iOS apps, it’s preloaded with all the iOS interface elements to scale. It also provides a map of the interaction between the pages. Blueprint helped to rationalise my wire framing process.
What’s especially useful is the preview mode which lets you navigate your app at iPhone size on the iPad. Even better Groosoft have created a free blueprint player for the iPhone to play your wireframe directly on the iphone. What’s really great about this is the fact your client can download the app too and test your wireframe/prototype with it and understand the way the app will work for themselves.
One drawback with Bluprint as it stands at the moment is the interface elements themselves. They are the standard native interface components and one thing you soon realise once you start looking closely at more recent apps is that the user experience of apps like Sparrow and Tweetbot are some of the newer ways that have been devised to interact with a phone. You can probably use components in creative ways to get the same results, and like all the best iOS apps it is being updated all the time.
I must admit I did find it a bit slow to work with. Nothing to do with the app itself, just that I find working with a touch interface a little tricky, and it gets frustrating when things start to get fiddly. There goes the idea of turning the iPad into a work device then, at least for this kind of work.
What Blueprint really did well was produce an interlinked set of screens on the iPad/iPhone to produce a working touch screen prototype. This was invaluable for considering how the app would flow from screen to screen and really understand how it would work.
Because of the ease of adding ‘features’ (when I say ‘features’ I actually mean labelled boxes with no real thought behind how said feature would or could be programmed) – the prototype served a crucial role. It made us realise that the app was trying to do too much. Instead we should concentrate on it’s primary role – easily scheduling content – and do that well rather than trying to add too many other things or turn it into something it wasn’t intended to be.
The prototype was the perfect vehicle to make this very clear. Features were trimmed back, the main user journey of the app was given greater thought, the prototype revised, and then the fun of doing the actual graphic design work could begin. We will look more at this in part 3.