Beacon

Dates

Berkeley CSUA Hackathon, May 2-3, 2014

Built With

Larry Cao, Kenneth Lin, Kevin Chen, Elizabeth Cheng, Clare Lin

My Role

I took on the role of both UI and Interaction Designer. Understanding what kind of interaction was most important for the app led to the overall design, as well as helped us iterate through early UIs.

Tagline

Free food, cool stuff, stranger danger? Be a beacon. Tell those around you with the push of a button. And the world will listen.

Technologies

It uses iBeacon technology through Bluetooth LE from the iOS7 SDK. Sends location-based “beacons” (signals / notifications) to all people in the area without the use of GPS.

Sketches

To start, I drew lo-fi wireframes for different ideas of how the app could look. Since our original idea was a big button, my first sketch was of a skeuomorphic button with the phrase “What’s happening?”. When a user started typing, the phrase would disappear and their beacon would be written in its place.

Then, as a group we played around with other ideas for the name, and words that sounded good together. Another word we liked was “beckon”, with its similarity in sound and syllables to “beacon”. and I tried encorporating it into my next design.

I thought about how users would want to know they were receiving beacons or not, since the technology would work with their app closed and screen off. I believed users would also want an easy way to turn it off, in case of meetings or classes. This design featured two buttons — now rectangles instead of buttons — that controlled receiving notifications (beacon) and sending them (beckon). When pressed, the beacon button would pop up a pulsing radar image, and when beckon was pressed, it would open a “What’s happening?” box like in the first sketch.

All this can be seen on the first page of my sketches.

I made a nicer version of this design in Illustrator, to get a more full effect and in order to show my team. The right image below is what the app looks like when you open it, and the left image is the app when both buttons are pressed.

At this point in the hackathon, we had decided that the word “beckon” did not fit our multi-purpose wants for the app. Beckon means “to gesture for someone to come nearer” but because we wanted people to send any kind of beacons, including things like safety warnings (for which you inherently do not go nearer), we decided to only stick with the word beacon.

After showing this design to my team, I received mixed feedback. People liked the two colors, and liked the font, but did not necessarily agree with having a large button with a pulsing image to denote that it was receiving beacons. One person said that it would actually make them worry about using this app, because it was so big and radar-like.

At this point, we started thinking more about the interaction we were interested in, and could not think of a good transition for the main screen when the keyboard was in use (because of the two buttons using the entire screen separately).

Iteration

I decided to go back to our original interaction — one button. It was simple, clean, and very easy for the user to figure out the main interaction without getting distracted by other things on the screen. But we didn’t want just any skeuomorphic button image. I was inspired by apps such as Shazam to create a button that followed the iOS7 Flat UI design principles while still feeling like a button.

Also, after doing a mini-survey of other iPhone app layouts, I noticed that many apps have inherent swipe movements to open sidebars for things like settings or navigation. An iPhone-owner in our group told me that he even expects that when he swipes on an app it will open a side-screen. We encorporated this into the newest design. The sketch can be seen on the second page of the notebook at the top photo, and the Illustrator version is seen below.

The Illustrator Mock

The Final App on iPhone

Conclusion and Lessons Learned

I learned a lot from this hackathon project. Designing for a mobile app does have its constraints, but that structure helps creativity flourish. Designing a mobile app UI is not only about making something that looks good and has easy-to-learn interactions, but is also about keeping the design within the programmer’s ability, as well as the hackathon time limit to implement. Especially at a hackathon, I cannot expect every design to be implemented to a T in the real app (for example, we did not have enough time to make the history page fit the UI designed for it). And finally, designing a mobile UI includes exporting the images in the correct size and format (which takes time) on top of providing the mock-ups.

For more images of the mocks and final app, view the Behance portfolio piece.