SureCall
Where this started
A booster in the wrong spot does not improve the signal
SureCall builds cell signal boosters and worked with Verizon on a phone app that helps people figure out where to put one. The app does three things: it tests the signal where you are standing, it confirms the booster is working once it is mounted, and it explains enough about 5G UW that the numbers mean something. People use it in a garage or a crawlspace, so it had to be fast, readable, and hard to get wrong.
Boosters go into garages, basements and rural houses where the signal was already bad. Two kinds of people install them and they want different things. Technicians do this all day and want the raw signal number. Homeowners do it once and want to be told they are finished. I had to give the homeowner a plain answer without slowing the technician down. Verizon wanted fewer support calls, and most support calls come from someone who could not tell whether the booster was working.
How do you tell somebody the install actually worked, without teaching them what dBm means?
Project Location
Silicon Valley, California
Nobody knows what minus 80 dBm means, including me at first
- 01
Turn a live signal number into a word a person can read quickly.
- 02
Explain what 5G UW is without making anyone read a manual.
- 03
Work for someone on a ladder, in a basement, with one hand free.
I never spoke to a user, and I am not going to pretend I did
I did not run my own research on this project. I worked from a brief written by the SureCall and Verizon project managers. It said three things: customers do not know what counts as a good or bad dBm value, people want to "see it work" before they believe it, and instructions have to be skimmable, with the detail underneath. We built two personas from that brief so I had a specific person in mind while drawing each screen. Those personas told me what SureCall and Verizon believed about their customers. That was the only information I had, and it was better than designing for myself.
I had no research of my own, but I did have a user, described in the brief. I think student work usually either invents findings it never collected or designs for nobody in particular. I wrote down what I was assuming instead, so someone could check it. Every decision on this page comes from a line in that brief.
I sketched first, because a sketch is quick to throw away
I sketched rough concepts to work out the flow, the screens, and which features were worth keeping. Sketches are fast to draw and easy to lay side by side, and I would rather throw out six sketches than one prototype.
Client work changed how I sketch. When a client is paying you, there is pressure to bring something finished, and if you finish it too early you spend the meeting defending it instead of testing it. So I started bringing three rough options instead of one finished one. People will tell you a rough drawing is wrong, and that is what the meeting is for.
Deciding what stays on the screen
This page only has to tell you whether the install worked. For every element on it I asked whether it helped answer that question, or whether it was only there to look thorough. Most of them did not answer it, so I removed them.
I think deciding what to take off a screen is harder than deciding what to put on it. Adding is easy and it feels productive, because you can justify each thing you add on its own. I have never regretted taking something off a screen, and I have regretted keeping things on nearly every project I have worked on.
Showing the word Good instead of minus 80 dBm
A color coded meter with plain labels ("Good", "Great") translates the signal reading, so nobody has to learn what dBm means to find out whether they are done. The app rescans on its own once the booster is mounted, because that is the moment you want the number. The raw RSRP value stays on the screen for the technician who wants the real reading. Both people get what they need from the same screen, without switching modes.
You should know the booster works before you climb down the ladder
The test finishes in a few seconds, so you are not standing on a ladder wondering whether to take the booster back down. These installs happen in the worst rooms in the house, so a clear pass or fail mattered more than a detailed readout. Nobody standing in a dark garage is going to read much.
The finished prototype
The design kit
How it turned out, and what I would change
On this project I learned to design for the room the app is used in as well as for the screen. Bad light, a ladder, and one free hand: designing for those conditions made me cut things I liked, including a detailed signal history screen that nobody standing on a ladder is going to read.
Working at a small company meant I was involved in every step. The part I valued most was sitting with the backend engineers and watching what actually gets built. They told me to change things based on how easy or hard an element was to code, which was humbling at first and then just useful. Thank you to SureCall for having me.
What I learned here was how to work when the research belongs to someone else. I had a brief, two project managers and no users, and I had to decide which lines in that brief I was willing to build on. Most client work is like that, and no class had asked me to do it.
I was nervous for most of it. It was the first time I designed something a company was actually going to ship, and I spent the first few weeks expecting someone to tell me I did not know what I was doing. That went away once I stopped treating the brief as a test I could fail and started using it as the description of the user I had. I left more confident than I arrived, which I had not expected.
How I would change this today with AI
The app tells you the signal is weak. It does not tell you what to do about it. Today I would let someone describe their house in plain words, or take a photo of the room, and have a model suggest where to mount the booster and where to put the outside antenna. That is what every support call is actually asking, and right now the app leaves it to the person standing on the ladder.
I would keep the live reading as the thing people trust. The brief said customers want to see it work before they believe it, and a sentence written by a model is not proof. The model can suggest where to try next. The meter still has to be the thing that tells you that you are done.
What I learned
Design for the worst conditions, not the demo
Bad light, one free hand, and a garage with no signal. Every screen had to work the first time, because nobody installing a booster gets to try again later.
Engineers will tell you what is cheap to build
SureCall's backend engineers told me which parts were easy to build and which were slow, and that changed what I drew. Now I ask them before I draw instead of after.
