At the beginning of the month, Redgate sponsored Talk UX. Revathi and I went to Manchester to attend it, and we’ve been talking about it to whomever wanted to hear. These are some of the questions we have been asked, here is what you’d have heard us say if you were there too… How was… Read more »
We’re excited to announce that we have just released our first iPhone app – Out of Office for Outlook.
Forgetting to set your out of office before you go on holiday can be a real nuisance. Our app solves this problem by letting you turn your out of office on direct from your iPhone.
This post describes design work that went into making the app.
In total the app took the two of us, Ben the developer and me the user experience designer, about 5 weeks from start to release. That includes the week we waited for the app to be approved!
Here’s a very rough break down of how my time was spent:
- Research – 0.5 days
- Basic interaction design – 0.5 days
- Visual design – 5 days
- Persona generation – 0.25 days
- Marketing strategy – 2.75 days
- Website design – 2 days
- Website implementation – 3 days
- Blog posts – 2 days
The remaining time was mostly spent setting up accounts and applications, discussing ideas, testing the app and asking other people in the company for help with various things! If we were to do a similar sized app in the future we think, now we know a little bit more about what we’re doing, we would be nearly twice as quick.
I’m not going to elaborate on all these activities, but I will outline the interaction and visual design processes.
For this app, deciding what features to include wasn’t difficult. Microsoft Exchange only supports a limited set of options and we just wanted to recreate what Outlook already lets you do.
However, attempting to translate even this simple UI for mobile wasn’t as straightforward as you’d expect. iOS doesn’t really have an equivalent to radio buttons or nested sub options. Once we’d looked at Outlook, and with these constraints in mind, we began sketching very rough designs. At the same time we looked at Apple’s own apps for inspiration and discussed the basic workflows our app would need to support. We didn’t go over the top with a full UCD process – the app just didn’t warrant it.
Unfortunately I didn’t keep our initial doodles, but we almost immediately moved onto Balsamiq to start fleshing the designs out in more detail.
Below, you can see the first set of wireframes. We were very conscious that for the app to do well it would have to look good. The app could easily have been just a boring settings page, but we wanted it to be appealing too. Adding a homepage where we could display a big graphic satisfied this requirement and a homepage also worked well from a UX perspective. The app therefore consisted of 3 main sections; the home page, the account page for connecting to your mailbox, and the settings page for actually configuring your out of office message. Another page would home the controls for scheduling your message.
We weren’t very happy with the single page design for scheduling your out of office, so in the next iteration we split it into separate screens for choosing your start and end time. We also added buttons for quickly jumping to certain times and began to think a little more about possible error messages.
This was a far as wireframes went. Once Ben had started to work on the UI it was easier to update that than maintain the mock-ups. Many of the detailed design decisions (e.g. which directions something should animate in from) Ben was able to take himself during implementation and I didn’t have to worry about – one of the benefits of having a design friendly developer! My efforts from then on were therefore mostly focused on the visual design.
The app required just 3 main images – two versions of the home screen and the product icon. Despite this, the visual design took around ten times longer than the basic interaction design. I suspect the ratio wouldn’t be this high if I was a better graphic designer, but I imagine it is normal for most (successful) small apps to have more time spent on their graphics than their interaction design.
I began by brainstorming different ideas and themes. Whenever I do this I quite like to dump a whole load of clip-art and photos into Illustrator and start to play around. This does tend to get messy quite quickly, but it works for me. Below you can see a whole load of photos pasted from the internet mixed up with my own Illustrator doodles.
The first concept I began to develop was just a basic cardboard sign. This didn’t take long, but failed to excite us. We were also worried if we used this as the main icon it would not be obvious enough that the app was related to email.
Next, I began to explore the concept of an open and closed envelope, the design gradually getting more intricate. The idea was that the open envelopes would show that you’re in and reading your email while the closed one would indicate that you’re out. To begin with the design just had a single envelope, but I didn’t like the imbalance in proportions between the open and closed state. By adding a few more envelopes I was able to make it squarer when the back was still closed.
We then had a slight crisis of confidence in envelopes (I can’t remember why exactly!) and I struggled to adapt the envelopes into an icon that would look good at lower resolutions. I therefore went back to the drawing board!
Midway through this process, we suddenly had a change of heart, and the envelope got a reprieve. I was now beginning to think about the webpage, and thought the mail theme would give us more to play with. The envelopes on a wooden background seemed to strike the right balance of fun / seriousness for our target user. We also decided that the app icon didn’t necessarily have to be exactly the same as the image on the homescreen so didn’t have to worry so much about how the image would work small.
Here’s one of the final images:
I added ‘In’ and ‘Out’ stamps to the envelopes to make the current state even more explicit, darkened up the background, and added the app title.
With the home screens completed it was then time to finalise the app’s icon. I experimented with the envelope for a while, trying to get it to work, but even after I stripped out most the detail it still didn’t look good on non-retina screens. So next I tried to simplify things by picking just a part of the envelope. I was really pleased with the red stamp, but because iOS doesn’t support transparency in its icons, the perforations looked rubbish against most backgrounds. I tried franking stamps instead, but we were worried they wouldn’t stand out in the crowded app market. In the end I settled on the corner of the airmail envelope. The red and blue helped make the icon stand out, and as we’d used the envelope on the home screen it just about fit with our theme!
There aren’t too many conclusions that can be drawn from our little app, but it has cemented in my mind the importance of visual design. This is the first time I have ever put anywhere near this much effort into making an app look good. It still might not not be “supermodel pretty”, but I’d like to think we can at least claim “girl next door” status. The sad thing is we’ll never be able to tell the affect this has on the number of downloads or calculate its ROI. If we were asked to justify spending so much time on the graphics we wouldn’t be able to with numbers, just the belief that it was the right think to do! I know it’s hard to prove the return on good interaction design too, but whereas efficient interaction design has the potential to cut overall development time and wasted effort, the same can’t be said of visual design. You just have to hope that the extra time will result in more users.
If only there was a way to A/B test apps…
If you’re struggling to set up a reliable, repeatable release process you’re not alone. The good news is that most of the problems you’ll encounter have been solved before.
There are many smart strategies you can use to create a fast, smooth release process that will give your entire team a competitive edge.
#1: Version everything
Source control for application code is a given.
Have a single source of truth that the whole team can use.