I worked at KnowRoaming as a co-op student from May 2014 to April 2015 (with 4 months of school in between). This was my first ever app design job, and had no supervision from a senior designer; it wasn't until my second term when the company hired a full-time designer. This experience helped me learn and grow a lot as a designer. The following is an attempt to capture my design process at the time.
KnowRoaming is a Toronto-based company looking to eliminate 'Bill Shock' induced by international roaming—that feeling you get when you realize just how much roaming can cost. Their Smart SIM Sticker, which sandwiches on top of your existing SIM card, acts as a second SIM while you're abroad. You are automatically connected to a local network through the Sticker, and pay only a small fee for roaming. The Smart Sticker comes with iOS and Android companion apps which are account management tools, used to to setup your account, manage your balance and check usage and roaming rates.
I joined the KnowRoaming team in May 2014 as an intern, and as the company’s first User Experience designer. My primary task was to take their existing account management app, and rework it to improve the flow and experience. In coordination with the stakeholders, COO, developers, and customer service, I reworked everything from the registration workflow, to the in app experience at home and abroad using the KnowRoaming SIM Sticker. The design process here was extremely iterative, done over a period of two 4-month work terms, and doesn't quite fit into a nice structured narrative. Nevertheless, here's an account of how the KnowRoaming app was designed.
To get a sense of what I was dealing with, I took the first few weeks to really get familiar with the current app, and how the system is intended to work. The KnowRoaming service is really quite complex—using the phone's own OS, the SIM card, and cell networks all over the globe to get users connected.
Since my job was to redesign the app and not the company's entire business (after all, I was only an intern), I started my journey with a simple heuristic analysis of the app based on Jakob Nielsen's heuristics. While not a true heuristics analysis (it was only me looking at the app), this analysis turned up some interesting insights. Below is a table I compiled of some of the most significant usability "bugs".
|Usability issue||Severity (1-5)||Usability Heuristic||Recommendations|
|User is unaware what their KnowSim Serial number is, or where to find it without consulting manual||5||Help & Documentation||Provide easier method of finding Serial, & add documentation in app|
|User is unsure when they have set-up properly, and are ready to use the app||5||Visibility of System Status||Show salient feedback of the user's set-up status|
|Leaving the app is required for registration. This forces the user to restart the registration process||5||Flexibility & Efficiency||Return the user to the same location in the app. Make use of OS multitasking|
|User is unsure whether they have signed up properly due to lack of feedback while processing the registration||4||Visibility of System Status||Provide feedback while communicating with server after sign up|
|Warning about Network Status appears nearly every time user returns to app||4||Control & Freedom||Show System popup only when the user opens the app in a distinctly different geographical region|
|Wizard in app breaks operating system convention||4||Consistency & Standards||Redesign home page to provide necessary salient feedback, and frequently used functions|
|Sign out is unforgiving (no confirmation)||4||Error Prevention||Add alert to confirm sign out|
|User must press an unfamiliar icon to view their account balance||4||Visibility of System Status||Make the account balance more salient.|
|Some screens are cluttered and many elements are not aligned||3||Aesthetics & Minimalism||Re-design most screens, & re-write text|
The findings weren't all negative though. I made a note of these elements, and they were used as important design criteria for the redesign of the app—the new app shouldn't be worse at something than the old one (unless absolutely necessary).
Shown in the screenshot above, the app displays the user's current network status front and centre. The visibility of this status is important information when arriving abroad, for quick troubleshooting and for peace of mind.
With individual research established, I wanted to get some frontline information from people who are more familiar with the app. I had no way of directly contacting existing users unfortunately, so I had to settle for some second-hand information. Thankfully we had a great support team who were in contact with users daily. I asked them to compile a list of some common issues users were having in the app, whether these were issues they were calling in about, or issues in troubleshooting. This provided me with some good confirmation of the issues I had found in the heuristic evaluation, as well as some new insights that I had not thought of.
Along with the list of usability issues, I asked for some basic demographic information of our users. From this information, and some interaction with individuals who generally fit the descriptions, I was able to create three personas of our users. To keep it brief, I've limited the personas to an intent quote here.
I’m going on vacation next month, and I'd like to be able to contact my family & friends back home while I'm gone
My job is to travel, and I'd like to be able to use my phone during my downtime without paying ridiculous fees.
I travel a lot for work, so I need to be able to contact clients, and for them to contact me wherever I am.
With the data I now had about the intended and actual use of the app, I was able to do a task breakdown to organize the actions involved in different activities in the app. Primarily targeting first time users, I broke down the tasks involved for a new user to start using the product, since many of these actions also need to be done by existing users before using the product again.
With the amount of unique actions needed to register and get ready to go, there was an opportunity to improve the app greatly.
Once I had a good picture of the service and its users, I started sketching and making some wireframes for different parts of the app. I was at the company two seperate work-terms, and continued my work on the app where I left off. The design process here was incredibly iterative, and the design of some app sections informed and changed the design of other sections. I've tried to lay out the design process as clearly as possible.
I started the redesign with the account setup workflow, since it was the first and most frequent task users would do in the app, and could potentially be a major source of friction for customers.
The main principle I used for registration and setup was good feedback—a concern we heard frequently was that users were unsure whether they had set up their account properly, and weren't sure whether they were ready to roam.
After looking into all the tasks required to setup an account and discussing with management, we decided that purchasing a foreign number is not necessary on setup, since it's pretty tedious to do on initial setup.
A core offering by KnowRoaming is called Call Forwarding, a service that allows you to get calls on your home while abroad. To enrol in this service, a user would have to purchase a phone number their home region, and set up forwarding on their home SIM. Since several users were confused at why they would have to purchase a local number for a roaming service, we decided to re-brand the service as ReachMe, which cost a monthly fee and required a single button press to activate in app.
For a user to know that they're "Ready to Roam", we would need to provide good feedback. Early sketches showed this as a basic checklist, but later involved more elegant representations of these steps.
While this version showed status it wasn't entirely clear that actions should or could be performed. The next iteration showed a flow more clearly.
With account feedback seeming to bleed into design of the home screen, I shifted my efforts there.
The home screen is the first page a user sees after registering, and every subsequent time they open the app. As such it needs to clearly show all the information a user might need. From the support team's insight into user needs, and the potential for error if an item is not seen, we were able to rank design elements and user actions into a hierarchy.
I used this hierarchy to inform the home screen design, and the app's information architecture.
A Dashboard-style homescreen would allow nearly all navigational components to be easily salient and discoverable. However, with at least 8 different actions with different relative importances, there was a high likelihood that the interface would become cluttered quite quickly, especially if new features would be added. I could make more important elements bigger, and lesser ones smaller, but the risk of clutter remained.
As you might be able to tell, this sketch came before the "Ready to Roam" paradigm was finalized.
A major benefit of a navigation drawer is that it allows all navigation elements to be viewed simultaneously in a list. The nav drawer also provides a greater area of screen space to be used to display more important information.
I put a drawer in into the dashboard design using the main screen for the high-importance elements placing the items of lower importance in the less-salient Drawer. This iteration of the top-level navigation pattern was used while designing other elements of the interface.
I did have qualms about the drawer though, for discoverability reasons.
A tab bar is ubiquitous on both iOS and Android. With the ablility to show highly important information and actions with a default tab, place others in the tab bar, and even more still in a now-common "More" tab, the tab bar seemed like the best route to go.
While there are still some elements hidden, the more frequently used items are in the bar. This design avoids clutter that the dashboard had, and does not have the discoverability issue of the drawer (thanks to the word "More" under the hamburger icon).
Using Prototype on Paper (now owned by Marvel), I made prototypes of these navigation patterns and tested on co-workers, friends and family. In retrospect I should've tested more rigorously, but time constraints (and inexperience at the time) were a major limiting factor at the time.
There are a number of cases in which the app can be used, and the app should behave differently in each scenario. I worked with the product team to flesh out what these use cases were, and what actions needed to be performed when.
The first use case is At Home. This is (ideally) where a user will do most of their account setup and management. Things like setting up a call forwarding number are not technically possible while abroad, so this action should be encouraged while on the Home SIM.
When a user arrives abroad, neither Android nor iOS will fully setup a data connection, so the first thing a user must do when arriving abroad is set up this connection. Once the data connection has been established, users can use their device just like at home.
You might think this seems like the same as the first use case—and you wouldn't be entirely wrong. It is very similar, only with one major distinction. While the geographical case is the same, iOS users arriving back home after being abroad will still have the KnowRoaming data connection. In order to return to their home data plan, users need to redo the same process they took to establish their roaming data connection.
From a UX standpoint this one was tricky, since this really shouldn't be necessary, but was due to technical limitations. It was difficult to counvince users that once arriving back home, their data connection wouldn't automatically reconnect like the regular cell service would.
Home SIM while Abroad / Abroad on Home SIM
In some rare cases, either (a) the KnowRoaming SIM will fail to connect/re-connect, or (b) a more advanced user will force a SIM switch. In these cases the actions available to users are different from the standard cases, so I'd have to take these cases into account.
With these use cases defined, it became clear that the previous home screen design wouldn't quite cut it. A user on the home screen at Home (yeah, this terminology got confusing, but "home screen" was only an internal term and user wouldn't see it, so we kept it) might see two of the three bubbles filled, and be lead to believe they weren't ready to roam, when in fact they had done all they could for the time being.
The solution was relatively simple—remove all options in the checklist that are not possible in the user's current state.
Once the major UX flow was mostly decided, I took to designing and refining different UI elements.
When redesigning the account top-up/reload screen, I pressed for user editable amounts to allow for the ablility to top up with a precise the amount that the user wanted. This was vetoed for logistical and support reasons, and so I had to design for a number of discrete reload options, as well as the same number of Auto-Reload options. I quickly realized that if I put all the options on the screen at once, the screen would get really crowded, and likely overflow off the bottom of the screen. Trying o find ways to efficiently layout this information, I took inspiration from the Starbucks app at the time, which had a horizontally scrolling row to select how much you wanted to put on your Starbucks card. The idea would be to have enough horizontal room for 4.5 cells, which would cut off one cell and imply scrollability.
I brought this idea to our lead iOS developer, and we brainstormed ideas on how to implement something like this. She came up with a rotated custom list UI element which worked perfectly. I was happy with the result, and we implemented this for both the Reload and Auto-Reload amounts.
Another tricky screen to design the layour for was the usage screen. I tried to come up with some creative ways of showing a user how many minutes, messages and megabytes they had used in the past day, week, month or year. I had several pages of mockups showing different charts and graphs, but I couldn't get all the information and options laid out nicely on the screen. We finally decided to keep it simple, and go with a basic list of all the events within the given time period.
Even when keeping the data simple, allowing selection from both four different time ranges and three different types of usage was a challenge. The instinct would be to use two layers of segmented controls, but after mocking that up and making some prototypes, these designs didn't seem right. The segmented control pattern is rarely doubled up in practice, and generally works as a secondary tab bar. A backup pattern would be needed for one of either the time range or usage type.
To solve this problem, I still went with a similar pattern, but with a different type of interaction, in hopes that it would be less confusing to users than a double segmented control. (In retrospect, maybe a double segmented control wouldn't be that bad... We should test it). The
There have been many blog posts about designing for the thumb zone, or sometimes the "stretch zone" as it's sometimes called. There are three rough regions on a mobile device: easy-, ok- and hard-to-reach with the thmb for a single handed user. When I was laying out components in the UI, I kept the thumb zone in mind, and kept priority interacion zones within the easy- or ok-to-reach zones. The hard-to-reach areas should be reserved for feedback-only or infrequent interactions.
Everyone hates pop-ups, but sometimes the're necessary. However, previous versons of the KnowRoaming app overused pop-ups, showing one essentially everytime a user returned to the app outside of about a one hour window. There were some pop-ups that were necessary though. Certain pop-ups contained highly important contextual information when a user arrives abroad or changes networks reminding them what actions to take. I took to redesigning this reminder to first make it fit btter visually, and second make it convey the information (hopefully) more clearly. This reminder will appear only once every few times the user ooens the app (I don't recall the exact interval), as well as when a cell network change is detected. Users also have the ability to disable the notification.
Early in the design process, I tried using some fonts from KnowRoaming's logotype and marketing materials, specifically Brandon Grotesque and Futura—two approachable sans-serif fonts. These mockups never seemed to look right since these fonts were designed for print, and weren't always readable on the phone screen. After exploring some other fonts, I decided that the simplest decision would be to use the system fonts: Helvetica Neue for iOS (at the time), and Roboto for Android. After experimenting with several fonts while designng both the app and other graphics, I was able to create a style guide which includes colour, typography, logo use, and other elements. Also included in the style guide guidelines for colours and font weights to use on different background colours.
Also included in this style guide, is a colour guideline. When KnowRoaming had hired a full-time graphic designer, the two of us worked together to standardze the colours we used, and for what functions in the UI. Since the company logo had already been designed, it was only natural to use the included light and dark blues as the primary colours in the app. Additional blues were selected as button-press states, for dark text, and a light blue as an off-white background.
We also outlined secondary colours: Gold, Teal, Red and Lavender. These colours all had specific functions and meanings in the app.
Since I was one of the original ideators of the ReachMe service branding, I created a logo for the unique service. The design was fairly straightforward, and to be honset, derivative. The icon uses the bubbles featured in the company logo, connected with lines to signify connectedness. The logotype simply echoes the company logo font weights.
On the home screen, icons representing the user's current state, the actons they can perform in that state, and tab bar icons were all necessary. To create these icons, I first took inspiration from existing iconsets on sites like Iconfinder. Based on some common symbols, I created an icon set in a unified KnowRoaming style—a thin stroke with rounded end-caps, in keeping with the iOS design language at the time.
The "Setup Data" icons were interresting to design, since they were fairly unique compared to the other icons. I started with a (hopefully) ubiquitous symbol for "internet"—the globe—and added elements to symbolize the state of being abroad or returning home. After some iterating on these elements, I arrived at the following icons.
To close this massively long article, I'll say that this was an amazing experience, and I learned a lot independently about design; the process and the craft. If I could go back and do this again, I would definitely invest more in true user testing. We didn't have many resources, so most of the testing was done on co-workers, friends and family—a process I like to call "guerilla user-testing". Actually reaching out and talking to users (something that terrified me then, and still does a little), as well as investing in user-testing software (like usertesting.com) would likely have sped up the design process. Creating some designs and getting feedback within a few days could have given me real answers as opposed to educated hunches which were never really proven.