Safedome

A CASE STUDY

Safedome is an ultra thin smart card that keeps an eye on your wallet - or anything else you don’t want to lose - using your iOS or Android smartphone. Safedome connects to the Safedome app via Bluetooth and sends quick alerts if you and your wallet separate.

I am going to use Safedome as a case study to demonstrate some of my UX processes and practices.

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. The information in this case study is my own and does not necessarily reflect the views of Maxwell Forest.

Understand the problem

One of the first things I try to do is understand the problem we are trying to solve. There are a few techniques to do this but all involve good old fashioned research and asking questions.

You need to research who your users are. Observe them either trying to solve the problem or interacting with the product. These observations should happen in lab conditions and also in the users day-to-day life if possible. What devices are people to use to access your product (people behave very differently on their phone compared to their laptop)? What time are they going to access your product (on the train, at home, at work etc)?

Safedome

What type of product are we designing?

An app for mobile devices and a hardware Bluetooth connected tracker.

Who are the main users?

People who are concerned about losing their personal items.

Where is the product being used?

It should be a passive, always on experience that only notifies the user when neccesary.

Why do they need it to exist?

So they can feel safe and secure and go about about their lives worry-free.

How will it be used?

Once set-up, users will only only be notified when they need to take action. This action will vary depending on situation.

Conduct interviews and surveys, whatever is necessary to build a robust picture of your potential users.

I conducted several UT sessions in our in-house lab focussing on early builds and concepts of Safedome. All of our test participants were from America as that was the region we were targeting. Certain interactions with the Safedome card had to be approximated because certain elements were not built.

This research will reveal a lot of data that feeds into every product decision and will help define product requirements.

I always aim to make sure that anything I do falls into the sweet spot of desirable, viable and feasible. For example, we could tie a bungy cord to everyones wallet so they would never lose it. Obviously that's not too feasible!

User journey

I began to outline the user steps of why, when, where and why the user will interact with Safedome.

Craig checks his Safedome app to make sure he is connected to to his wallet.
He gets to the office, dumps his stuff down and rushes to his first meeting.
Craig receives an alert on his iPhone notifying him that he has become disconnected with his wallet.
Knowing he regularly leaves his wallet on his desk at work he decides to quickly create an Alert Free Zone around his office.

Craig heads out to lunch and unknowingly drops his wallet after paying for his meal.
Walking away from the cafe he receives an alert on his iPhone.
Craig rushes back into the cafe and sees his wallet on the floor next to the counter.
Utterly relieved he picks it up and puts it in his pocket.

From this I started to explore User Stories which are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile User Stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. They can be written at varying levels of detail (epic = big) and can be split into numerous smaller stories that can be worked on in sprints.

As a user, I want to receive an alert so that I do not lose my wallet.

Once the user journey is mapped we can start looking at what the potential flow through our product could look like.

Sketching

Sketching is such a powerful way to quickly communicate ideas that in my opinion it is still unmatched in its ability to create disposable low fidelity designs. I sketch a lot. Whether it is in my notepad getting my ideas recorded or on a whiteboard to communicate a new type of interface you will generally find me with a pen or pencil in my hand. It allows for less preciousness around any design, everything is so much more disposable in this format and that is exactly what you want at this stage. It also encourages broad feedback ("How do I get there?") as oppose to narrow feedback ("I don't like that font") which again is exactly what is required at this time.

Wireframes

I tend to combine my early wireframes with my projected flow of the product. They inform a rough guide for the layout. They should be clear and simple, no visual design or aesthetics here. They can serve as a good conduit with the stakeholders, signing off on placement/flow (broad feedback) etc rather than getting bogged down in font choice (narrow feedback) etc. Include lots of comments and annotations on them.

Mood boards

With Safedome I conducted mood board and colour exploration to run alongside flow and wireframe development. The reason for this was to lock in brand identity so pre-sales exercises could take place while Safedome was being built.

Prototypes

Once wireframes have been created (and continued to work on) I began to explore flows and interactions. The best way to do this is by creating prototypes. How do you get from one area to another? I will use Invision for this part which is perfect for providing a holistic clickthrough experience. Where Invision falls short is in exploring micro-interactions - how screen elements act and react with each other. This is where you can really surprise and delight your users. I generally use Principal to do this exploration but it’s a fast moving area and there are lots of alternatives!

Please note I have lots more prototypes but am bound by NDA's around what I can show here.

Testing

How many test participants you involve, how closely your test participants match your actual users, and how many iterations of testing you run are all decisions shaped by budget and time constraints.

Usability testing is straightforward enough that anyone can - and should - experience running one. Being in the same room while someone uses your product is a powerful trigger for creating empathy with users.

I wrote comprehensive reports detailing every interaction the subjects experienced. I created a scoring system and prioritised each finding and logged them back into Jira.

I also conducted several click tests that generated heat maps. This allowed the team to see where on the screen people were naturally drawn to. You always get surprising results which is great and exactly what you're after!

High Fidelity

I tend to start introducing elements of high fidelity design at the prototyping stage. I also developed the app icons across iOS and Android as well as delivering high fidelity assets to the development team.