This site uses cookies for analytics, personalized content and ads. By continuing to browse this site, you agree to this use.


How we streamlined our design process by creating a device simulator app

23rd March 2016

At SwiftKey, we hold regular Innovation Days (or Weeks!) during which we team up and work on a problem or project that interests us. On one particular  Design team project, we aimed to shorten the journey between the initial design concepts and the accurate preview on various mobile devices’ screens.

In my role as a User Experience (UX) designer for mobile apps, I am often challenged to come up with User Interfaces (UI) that will work on a plethora of devices. There are thousands of different mobile phones and tablets out there, with various displays that can render the same image in a different perceived scale depending on their screen’s specification (if you have ever had a discussion about the physical size of a pixel, then you know this issue is something that can affect the way the designers work).

On the other hand, users don’t really think about or need to be bothered with that. All the user is interested in is how the application looks and works on their mobile device. For the users it’s about the physical – not digital – world measurements and the usability as much as it is about the visual appeal. A device’s keyboard is meant to be used on a daily basis, not to be looked at on a presentation screen. So the best way to make sure the users come first is to experience the design concept on different types of mobile devices as early in the design process as possible.

The reality is that getting access to all of the devices that exist in the world just isn’t possible. Even if they are available in the SwiftKey office, they might be in use by someone else. So one Innovation Day, Lachie – an engineer at SwiftKey – and myself came together and decided to do something about it. The idea was to create a simulator that lets you preview how an image would appear on any device. We brainstormed what would be the minimum functionality and sketched initial designs together. We decided to focus on a tablet app. A tablet’s screen is physically larger than the majority of mobile phones, so it can simulate most of them. We worked side by side for a couple of days solving any issues on the spot, and this is how MobiView came to be.

MobiView is a tablet app that allows us to create many virtual devices, assign a few parameters to them (e.g ID, pixel width, pixel height and density of the screen), and then preview images as they would appear on the actual device. If an image is too large to fit on the virtual screen, the app marks the cropped edges. It also supports orientation change so you can see how the same image would render in both landscape and portrait; the preview doesn’t scale to fit the screen, it keeps the original size instead. Images can be loaded via Google Drive or directly from the camera roll.

We soon had a chance to test it while I was designing one of the core feature implementations – the punctuation slider for SwiftKey Keyboard on iPhone and iPad. Although the keyboard UI stretches to match different devices’ screens, the swiping areas and touch targets don’t change by the same logic. Users’ hands don’t tend to scale… at least not in time-frames that can compete with our product releases!

We used MobiView to create a range of virtual iPhones, including the newest at the time, and trickiest to design for: the iPhone 6 Plus. By tweaking the graphics and comparing them across different devices, we arrived at the visually consistent sizes that could then be calculated in pixels and coded in the app. I could actually touch the images – normally on the iPhone preview the images react to touch (and animate), so it’s difficult to verify the scale in the realistic scenario when the tester’s finger is in the way.

Towards the end, solving a process issue led to an innovative approach to a design problem. Can it really replace the functional preview on the final device? No, but it is a good starting point, and in some cases the only way to see a rough design preview on a specific screen type. It’s also easy to carry around to meetings, and there’s only one device that needs to be charged.

We thought this was a good approach to improving the design process. Do these issues/concerns sounds familiar to you? We would love to hear your stories – share them with us on Twitter!

Anna and Lachie