designing a
mobile OS.

Meet TernOS, a mobile operating system designed to help travelers overcome language and cultural barriers through a contextual OS. Scroll down to view the process we took to getting to our final product.

View Final Product


10 weeks


high-fidelity wireframes
+ pitch deck


principal designer
+ researcher


jocelyn afandi
tiffany wong
evan whitcomb
dre magallanes
kylie helton

"You have 10 weeks to design a mobile operating system. Design out the core applications of that OS and then we'll have some people from the industry come and review them out of 5 stars. Good luck!"

- Brian Fling, the instructor providing us with the problem brief

Starting Out

Annnnnd go! That was it.  No assignments, no tests, just make a Mobile OS. It was both exciting and horrifying.

Our design team started ideating about what OS we wanted to make. Specifically, who it would be for.

We threw a bunch of ideas around until we landed on the idea of language learning. We all had parents and relatives who had different native languages, and from both experiencing and seeing the struggles that can come from both learning a new language, we were excited to explore that problem space and ask:

"How can we create a mobile OS that helps users learn a new language through a seamless and fluid mobile experience?"

- our group, describing the
problem statement

Initial Assumptions and Ideas

We were set on the idea, but we didn't really know what that would entail. We started thinking of some initial ideas about what this might look like:

A button to quickly change the language of OS (since we were allowed to make physical device altercations)

- An OS that slowly transitioned different part of the OS in different languages as you developed a stronger understanding of the new language

- Auto-translate for all outgoing communications

We presented the initial ideas, but were then faced with our first roadblock, asked in the form of a question: "What makes this an OS versus just a feature?"

Ah, good point. We didn't really know how to expand past just these ideas. I then realized we had a problem: all of us were english native speakers, and even though we might have have some family or academic training in new languages that wouldn't be a good representation of our users.

We also realized we were getting a bit ahead of ourselves, since the best way to figure out whether or not this product would be successful is first figuring out what our user group had trouble with with there experiences.

User Research

We wanted to make sure that before we pitched the idea for our OS that there were pain points we needed to solve, so we started doing several semi-structured user interviews with students who were either multilingual, or lived with family members that were non-native speakers of that area. We got 23 interviews in the next two weeks.

Here were the main takeaways:

of interviewees prioritized navigational and translational apps while traveling.
of interviewees were hesitant to try new things out of the worry of doing something wrong.
of interviewees wanted to explore past just the tourist traps while traveling.
dealt with higher cognitive load while abroad in a place that spoke a different language.

Okay, this gave us a better idea of how to tackle the problem, and it seemed like our initial ideas for the most part might be able to help with these pain points!

Lo-fidelity Development

From there, we started doing some low-fidelity wireframes and started looking at both individuals apps and how they could fit within the theme ("How do you make a calculator app adopt this theme!??!") as well as looking at the overall design systems within it, looking at how those components would adjust to the user learning languages.

Somethings not working...

Something still wasn't right, and it eventually hit us like a ton of bricks, which happen to come through the phrase, "This isn't working", during our design review.

They were right, we didn't really feel like we understood the language development process or how it could really fit in. A big problem we also had was handling global navigation versus app navigation, knowing what to do about apps that don't have very unique app structures, as well we weren't fully sure if some of our features were, well, helpful.

After we quickly messaged each other "gg" and other memes in our team's group chat, we then realized we needed to go back to the drawing board.

After both looking back at the research we did as well as the lack of information we had, we realized that we didn't have enough information for the language learning aspect. We did however have research on the experience of students who have traveled to countries with different reasons (tourism, study abroad, immigration) and who help their relatives who speak different languages. So we then decided to focus on this target group. Young adults (18-25) who were traveling to a new place who didn't understand the native language in that area. We lovingly gave that target demographic the nickname, "explorers".

So from then, we adjusted our problem statement to better fit the target group we could help:

"How can we create a mobile OS to help travelers in new countries overcome language and cultural barriers?"

- our group, describing our revised problem statement

Sweet, step 1 has finally been completed. Back to step 26...

Swinging for the fence

The next thing we realized that was blocking us what the idea about what an OS had to be. We were comfortable with the layouts of android and iOS, and thought we needed to mimic them. Our design professor told us to, "Swing for the fence!", so we sat around a whiteboard, and like the over caffeinated college students running off of 3 hours of sleep we pitched ideas about what our OS could be like:

- NO WORDS!! just icons.

- All through camera vision, google glass 2.0, you could saya toolbar for translating anything you saw on the screen, ready at any time.

- A mobile OS completely guided through voice

The camera vision one got us thinking, and then the idea of context came to mind. The needs of the user will change dependent on the context they have, so what if we created an OS that was centered around context. In this case, providing contextual guidance for the user so they can navigate new and confusion situations.

Taking off from where we were

To help flesh this out, we thought of user stories based on our users past experiences, and how we could design our applications to help support our users in those times. We utilized pocket-to-pocket journeys to see the entire scope of a user's interaction with potential apps

Through several iterations, a bunch of late nights, a very very intense 10 minute of all of us waiting zoom call for our large final presentation to submit before the deadline, and we had our very own OS!

The OS for Explorers: TernOS

TernOS, named after the artic tern which makes it's annual migration from the north to the south pole, is a contextual OS designed to help support explorers understand the language and culture of the place around them.

Our OS is centered around three main apps that were significantly more utilized than others: Camera, Navigation, and Translation.

TernOS Feature Overview
Access to Core Features

When it comes to the springboard and home screen, the main idea was to always have the three apps travels were using (navigation, translation, and camera) at the bottom for easy access, whether the phone was locked or unlocked.

In moments where you need these apps, you might be overwhelmed with the current situation and have a high cognitive load. Having access to those apps quickly would be vital to the users. Once they're using those apps and have captured some form of input, TernOS would then provide contextual solutions to help them achieve what they're doing. We called these TernTips.

Contextual help - TernTips

Tern Tips is meant to act as your contextual guide while using your mobile device. The idea is that based on the information the OS has, TernTips will take a guess at what you're trying to do and offer you solutions to solve whatever conflict you have.

TernTips is utilized in multiple forms throughout the OS, mainly in the three primary applications of our OS.

Picture perfect - Camera

Gone are the days of only using your phone to capture memories abroad, we wanted to expand the cameras usage to utilize camera vision for AR-style translations, but taking that a step further to allow TernTips to chime in to help you understand your surroundings better.

I mean, it's one thing to understand the sign says Tempura, but how will you know that it's a delicious panko-fried pike eel cullet popular in Kyoto Street Markets? That's right, TernTips can let you know.

Going to and fro - Navigation

We wanted to create an all in one style navigation app so users didn't need to jump through different apps. We loved how the Transit app works, and wanted to develop an application that provided you with several different ways to get to your location. With TernTips, we also wanted to provide the user with contextual clues with what the standard mode of transportation is, or whether or not calling an uber at 5pm in downtown manhattan when it's literally just a 10 minute walk and the uber cost 40 dollars Rober- Sorry, sorry. I got off track. All in one navigation plus contextual tips to recommend you the best way to go, simple as that.

Speaking easy - Translation

Whether it was understanding what a sign meant, or trying to test your texting skills with google translate in a conversation, almost everyone we talked to relied on some form of translational apps. We wanted ours to be clear and bold, since being in a situation where something as foundational as language is now foreign to the user and can overload their cognitive bandwidth. If you need to translate one word, you have a mode to handle that.

Life isn't lived one word at a time, so we wanted to provide a way to help users walk through conversations with individuals of different languages. So we designed a real time translator mode to help walk users through conversations, hopefully breaking down the language barriers.

This is the one time where TernTips is directly listening, and can pick up on whether or not a conversation is making progress or anticipate a way to help the user solve an upcoming task.

The final sell

We had our OS ready to go, now it was just time to package it up. Since we only had ~10 slides to work with, I pitched the idea of showing how our OS could help out both of our personas on different trips in different locations. The goal was to almost make them like individual advertisements, but all together showed the capabilities of our OS. So after using the first few slides to explain our main features, we walked through the journey of our user personas and sent it off for final review.

Where we landed

Out of five teams, we tied for second with a 4.8 star rating. After dealing with weeks and weeks of ideas not coming together, we all had a final product we were genuinely really proud of. We didn't end up creating other core apps of the OS due to time constraints (our pivot came late in the game) but we wanted to focus more on the apps that were the defining features of the apps, plus, we discussed how this could even be an additional device you had to support you on your journey. A lot of our feedback from judges were how we were providing intuitive solutions to common issue, and I think we wouldn't have hit that mark if we were still approaching it with the overall goal of creating something that was outside our capable scope.

We had some consistency issues that were picked up when it came to the wallet feature we were working on, so if we had some extra time we'd like to be able to clean those small points up.

My takeaways

This was a really great exercise in understanding how to design directly for use cases and then expanding that out to full systems. This taught me that you'll be more successful by starting out with solving user pain points and seeing what you can also help with, rather than just applying the same framework to a different problem space.

This also taught me a lot about dealing with failure and pivoting, we thought we originally had it figured out but when all of our feedback was showing that we weren't on the right mark we had two options, just hoping for the best and trying to salvage it, or be comfortable with letting go of our initial ideas and take another swing. It did mean that we had to really grind out the last few weeks since we were a little over half way through the quarter during the pivot, but that also taught us how to build more in an agile way through focusing on key apps first and then building out secondary ones.

If we did have more time, I really wish we could have tackled our original idea of helping individuals learn new languages or operate with a multilingual OS. When we were fleshing our idea I learned that over half the world was multilingual in some capacity, yet every OS we use is monolingual. Language is the gateway into new culture, and the barrier between one another can be covered in the barbs of racism, oppression, and stigmatization. Our hope was that this could be a remedy to those larger overall issues.

At the end of the day, even though we pivoted from our initial solution, I'm proud that we created something that was a more intuitive solution to actual problems rather than make assumptions about how we should solve this super large problem we weren't equipped to solve. I'm thankful to have worked alongside my team and with the support of our instructors Brian and Khang, and this project redefined a lot about how I approach user-center designed.

You could almost say, it was a terning point in understanding how to design in a user-oriented format!

aha.. you get it? turning point? tern? terning point?

ah, you get it. you get it.