We've all been there... A bad date. A conversation that should have ended five minutes ago. An uncomfortable walk past a stranger in a seedy place. We've all needed an excuse to get out of a bad situation... yet coming up with an excuse off the top of your head can be difficult. There is one fool-proof excuse that always works – a phone call. But unless you scheduled it ahead of time, you're kinda SOL.

Phoney is an app that I designed and (kind of) built over the course of 2019. What began as a simple idea ten years ago eventually turned into my first completely personal app released into the App Store.

Completing this app was a lengthy process in which I learned a lot. I've been profesionally designing apps for over six years now and products I've worked on have gone into the hands of millions of people around the world – but this project was my first end-to-end product.

Since I don't want to make this case study too long I'm going to cut out the details of the beginnings of this project and dedicate the majority of the content explaining the design and development – but I do want to take a moment to explain how this got started.


When I decided to build a tool that let me trigger fake phone calls, I was going to build it as a simple Principle prototype for personal use. I built a version for my iPhone XS (prototypes are not responsive layouts) based on publically-available iOS UI kits, made a few basic personas whom I could have "call me", and held it on my phone for a couple of months. After finding some use in it, I decided I would make versions of the prototype for other devices and then distribute those for free.

I spent a long time creating to-spec versions for each iOS device. Once they were done, I set up a spot for the thing on my Marketplace. Then, ready with my cursor hovering over the big red "DISTRIBUTE" button, I had a thought...

"This is useful to more than a few nerds willing to store a prototype file on their phone. I keep saying I want to learn to develop my own apps. I've tried but never built my own app or shipped a personal project. This app is simple enough..."

"...why not learn some Swift and build it?"

A completely unoriginal idea.

You know the classic old trope: Someone is going on a blind date, and due to the fear of uncertainty, they ask a friend to call them at some coordinated time to check in. If the date is going bad, the dater can use the call as an excuse to leave while letting the date-ee down easy. In Special Council Rober Mueller's "Report on the Investigation into Russian Interference in the 2016 Presidential Election", Donald Trump Jr. is noted to have texted his secretary asking her to call him to give him an excuse to leave a downward-spiralling meeting with Russian officials. A phone call provides a neutral out that's difficult to counter, no matter who you're avoiding. It's a trick that's nearly as old as the phone itself, just made easier and a more realistic tactic today thanks to mobile phones.

There have been some decent attempts at executing on this idea. Chelsea Handler has a standup bit where she expresses a desire for an app that made fake phone calls to get out of awkward dates, and ended up getting a developer to build one. It's called "Gotta Go!" and it's a fun app which shedules a real phone call with a recording of her on the other end.

Clearing the signal.

I used "Gotta Go!" for some competitive analysis and after using it for a quile I made a few observations which I could use to make my app better. The app is alright, but it's a bit restrictive and doesn't meet the needs of everyday situations. Some of the friction points with Gogtta Go! are:

    1. In order to receive an incoming phone call you have to schedule it ahead of time. This is great if you are anticipating an awkward encounter, like maybe a first date, but not in any other situation. I don't know about you, but I don't typically plan my awkward encounters ahead of time, they happen randomly and all the time.
    2. The incoming phone call is always the same recording. It also plays continuously and can't be interrupted. It is tailored specifically to the use case of the user being at dinner and needing to leave to to an emergency with a friend. It also begins with a loud "Hi, this is Chelsea Handler..." playing through the earpiece.
    3. The app is offers the ability to cusomize the incoming caller's name and photo, but it forces you to pick an emoji to represent the caller's profile from the main menu. This is confusing and can make it difficult to be sure who is calling you
    4. Caller profiles aren't the primary "actor" in the app. Instead, the user creates an "excuse" script where they can set a phone call and/or text message and then assign a contact from a roladex that the user manages separately. This increaseds complexity and leans towards being over-designed.

All of these factors make it dificult for the phone call to create any semblance of realism for the escapee to use to evacuate the scene. This is not to crap on Chelsea's app. In fact, I think the app is fun and handy. I just find it to not be as useful in real world situations where the need for this app is required. What I learned from asking a few people that I know and, well, living the way that I do for so long, is that there is one basic requirement for this app to serve people well – the guiding principle of Phoney's design:

Work in a variety or situations, and fool somebody who may know you or your acquaintances and may be able to overhear you as you try to make your exit.

This means that a successful minimum viable product must:

    1. Not require that calls be scheduled ahead of time.
    2. Provide the ability to cusomize the contact's name, photo, number, and voice type.
    3. Be so easy to use that you can activate a call without looking at the screen.
    4. Look and behave exactly like the native phone app. (Spoiler alert: I run into some trouble here)


To keep the app simple, I decided to that the MVP would only allow you to add contacts, see those contacts in a list, and activate a phone call from a specific contact. After that that base model was in place I could begin considering other features. There are two ereas that I wanted to focus on: features that enhance realism in a situation, and safety features to help vulnerable users get help in an emergency.


Assume the user is in a situation where they are with an aggressor and are using a call as an excuse to cause a de-escalation. In a situation like this, a user may want to have a set of emergency contacts with whom they could send a text alert or share their location. They may want to record audio or video.

Each of these features are possible to implement, and since the call screen already has a series of buttons on it, I was able to work in a crafty design where the standard "mute", "keypad", "FaceTime", etc. buttons were replaced with safety feature buttons. The most immediate problem with including these features is the development time, the need to continually update the features to keep them working, and the risk of confusing the user – I realized that I would be taking on a larger ethical responsibility, as well as possible liability.

Consider that I did include these features and just one user find themselves in a situation where they were reliant on them. Should my shoddy code fail – which is likely – I take on a personal responsibility for failing to provide safety service. The likeliness of this happening is small, but it does exist, and is not a responsibility that I feel safe taking on at this stage. I may build in these features later on, though.


Selling the fake call as a real thing relies largely on two factors: The interface blends into the native OS, and the phone call itself helps the user sell their story. Looking back at our problem statements, one issue with the existing fake call apps is that they play the same canned recording whithout allowing natural interaction from the user. But we definitely want some sort of recording on the other end, because talking to yourself in silence is even more difficult. If we want to sell the situation, the user should be able to hear a recording on the other end but also be able to say anything they want, whenever they want, and the recording needs to stop talking while the user is talking – just like a real conversation.

This is where I came up with a feature I call "Voiceback." The app has two audio libraries with dozens of different short recordings – one for male and one for female – containing a collection of short recordings of a person talking which play at random. The recordings are of neutral banter – "uh uh's", "hmm's", "tell me more's", etc., so that the user can say things that might be more relevant to the incoming caller's persona. You would say different things to your boss than you would your dogsitter, for instance. During the call the phone's microphone is on and recording. When it picks up incoming audio over a certain decibel threshhold the recording of the person talking pauses, allowing the user to speak. After a second of silence from the user the recordings begin to play again at random.

Not only does this sound more like a real conversation to anybody who could be overhearing you, it also replicates the feeling of a real conversation for ther user and makes the act of holding a fake conversation with yourself a little more comfortable.


When I began designing the interface I knew that the the app would be made up up of three main parts: The contact list, the contact creation/edit screen, and the phone call. Typically, visual design isn't considered much until the later-end of a project when all the primary arthitecure and UX work is done. But since Phoney is meant to be a "sneaky" app it had to be indistringuishable from the OS. The phone call screens obviously had to look like the native phone app, but the contact list and management screens also needed to take on the native OS look and feel. This has its pros and cons: It makes it very easy to design as I don't have to put much thought into the visual design, letting me focus more on freatures and a simmpler experience – but it also means that I have to keep up with iOS as they make changes in the future.

Fortunately for me, Apple hasn't changed the design of the phone call screens since iOS 7, so I'm probably safe for a while.

Contact list

The contact list is a series of cards building from the bottom-up. I chose to anchor the list and action buttons throughout the app on the bottom because it's more ergonomically friendly, and I don't anticipate people having more than a few contacts, so it's a bit friendlier to keep the content close to the thumbs.

The list is topped off with the "add contact" button which takes you to the "edit contact" screen. From here, you can add a photo, a name or phone number to display on the incoming call screen, set a Voiceback gender, and a ringtone. Furthermore, you can swipe left to edit an existing contact, and right to delete them.

Adding a contact

The "edit contact" screen underwent the most design work. Partly because it's the only real "custom" page in the app, but also because of a number of unforseen factors. I played around with different methods of grouping information and controls, considering the card metaphor I was using throughout the app. I played around with multiple versions, considering different ringtone and voiceback settings, before settling on a more prominent model which was inspired by iOS' control panel screen.

One of the most complicated issues to solve with this page was finding the right way to group the different input fields while keeping the contact photo and name on the same card. With my metaphor, the "contact" is the image and name inside of the tile, and the Voiceback and ringtone options are details that have "unfurled" from the contact tile. However, by putting the name label and image within the same tile, a lot of users miss either the photo and only edit the name, or add a photo but ignore the name. I was able to help teach users that they should edit both fields through the first-time onboarding experience, though I may revisit this page later to make the affordances more clear.


To complete the call experience, I needed to add a feaure that played a voice through the ear piece. It's not a phone call without someone on the other end, after all. Not just for the obvious reasons of it being more realistic, but to also help draw the user into the the experience more. If you've ever pretended to be talking to somebody on your phone, you may have struggled with your script and ended up mumbling through or switching between random phrases and filler words like "uh huh" ayd "yeah". As noted earlier, Gotta Go! plays a recording of Chelsea Handler talking to you by describing a situation and walking you through things to say, like an acting coach, to get you out of, specifically, a dinner date. It takes your mind off of your surroundings a little bit and focuses you on the call, which in turn is more realistic to any on-lookers than merely mumbling to yourself. Rather than playing a recording of someone talking, I wanted to explore ways that I could ditch a script and make Phoney fit into any siituation, not just a dinner.

What I came up with was rather simple but opens the user to talking about pretty much anything. Instead of one long recording, I created a library of small sound bites with random phrases that I put in the "casual banter" category. These are recordings of someone saying simple filler phrases like "Oh?", "Hmmm", "Ah", and "Oh yeah hmmm", to more conversation-driving phrases like "Is that what you were telling me about before?", "Oh that's interesting", and "You what?". To allow for a more custom experience, there is one library of a male-sounding voice, and one for a female-sounding voice, depending on which Voiceback gender the user sets when creating a contact.

When a call comes in and the user ansers the first recording that plays is a basic "Hey, it's me." It then starts cycling through the voice library at random with brief intervals in between. The microphone is open and listening, and if noise over a certain decibel threshhold is registered, the Voiceback pauses to let the user speak. After they are done speaking, the recordings continue to play. This lets the user experience a more natural back-and-forth that also helps fool the person they're trying to avoid.

Call swapping

To mimic the native phone app's behavior as much as possible, hanging up a call closes the app and takes you back to your home screen. This feature comes at a cost in that if you select the wrong contact to call there is no way to go back without re-opening Phoney. This isn't an issue I anticipate people running into all that often, but there's still a risk of causing a friction point for the user. In order to get around this, I introduced the ability to swap a call.

To swap a call, simply pull down on the call screen (both the "incoming" and "active" states will work) to go back to your contact list. From there, you can tap another contact and instantly launch a call from them. For increased ease of use, the call screen that you pulled down rests at the bottom of the screen and peeks up a bit, allowing you to pull it back up to continue with the call. This also effectively serves as a "pause" if, for some reason, the situation calls for it.

Buildin' the damn thang

Once the design was done it was time to build! Oh shit... it's time to build. At this point, I still know absolutely nothing about Swift or developing an app and I don't know where to get started. I perused the web for Youtube tutorials and StackOverflow threads before stumbing on the holy grail. A diamond in the rough. The fountain of knowledge or whatever they call it. There's a fantastic resource website called DesignCode which, among other things, offers great video courses on a number of design and development subjects. I was familiar with DesignCode and decided to sign up for their Swift course.

It went... okay!

I completed the course and built a semi-fucntional version of Phoney, but I wasn't able to get a lot of the basic elements in place. At this point I had a decision to make: I could continue to take courses and try to work out the issues myself, or I could enlist some outside help.

I find that I learn best by taking things apart. A lot of my design education came from studying and breaking down apps and UI kits that I loved. I learned what I know about web development by tearing apart templates. If I'm going to learn to build an app I need to watch somebody build my app and learn along the way. And what better way to find a willing partner than Twitter?

Incoming call: Alex

A mobile developer out of Germany responded to my tweet and said that he was interested in helping me. Alex is an accomplished developer who has lived and worked accross Europe building mobile experiences for companies like Volkswagen, and he was kind enough to offer his help. Incredibly, he offered to do the work for free, despite my urging to pay him, becuase he was happy to see a designer who was interested in learning to code – or at least better-understand how these things are built.

We got to work quickly and started meeting for a few hours every weekend over Skype. Alex broke the project up into multiple parts and we treated each portion as a lesson. Over the course of a few months we worked together to build the app.

How do you make a simple, silly concept exciting?

It's a little difficult to make a product like Phoney look exciting. Sure, you, dear reader, know it's an extremely useful and beautifully-crafted app that will surely win dozens of awards just based on the design alone... ahem... but to your typical consumer, it's just a list view, a fairly standard editing page, and a totally standard phone call screen that people have seen hundreds of times. Since I'm marketing this app, I needed to create assets that could catch people's attention and make this little Pinto look a bit more like a Ferrari.

Well, I have a trick up my sleeve. While so many others are stuck in a sad world of only two dimensions – I have THREE.

Our design tools have been betting easier and easier to use in recent years, and because of that our toolkits are expanding. Programs like Rotato and studios like LStore make it easier to place your screenshots into 3D renders. Some of the videos, like the ones used in Snapchat and Instagram ads (below), and the demo walkthrough video, required me to make multiple renders and stitch them together with some video magic. While considerable easier than making these things entirely myself in a 3D editing tool, this portion of the work was very time consuming and a bit tedious – but the results, to me, are amazing.

If you build it, they will come?

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.


I created a simple website to market the product and host additional information for customers. On the site, visitors can get a full understanding of the app, see beautiful product shots, see example contacts they can set up, view the FAQ, and of course, reach out to me.

Thanks for reading

If you like this project and want to see more, check out my full portfolio. If you want to connect with me, you can find me on these platforms.