IOT Case Study

A startup in Silicon Valley came to me with an interesting balance of 2 personas spread across web, mobile, tablet as well as their IOT Pods called Zen Spaces. The concept was that providers can host pods on their premise while guests can book from mobile or web and enter the pods using the attached tablet. But was this all working in practice?

All was not going as planned.

The Problem

The pods were always entirely manually set-up while it seemed no bookings of the pods were able to go through successfully without assistance.

The MVP created on mobile, web and tablet were technically offering all the basic features each persona needed to book. Despite that, the technology wasn't being used unless users were hand-held and set-up for each pod was a company-wide effort each and every conference.

Team & Methodologies

Jean Kaluza
PM, UX Research
Eugene
UI Design
Development Team
All platforms + Raspberry PI
User Testing
User test & observing at Conference around sales team
Qualitative Sessions
Brief questionnaire with participants after user test.

Research

How we did it...

User Testing & Qualitative Sessions

Flying out to a conference to observe users interact with the software was the first step in assessing where exactly the problems were. The challenge would be the sales team, whom had the opposing goal. While they aimed to give a white-glove experience with hopes of a sale, I let people on cellphones carrying laptops try to schedule a meeting they were late for through an experience they only just realized even existed. But, evil in the name of clean data, no? 😈

Test Subject Qualifications

Any individual that engages with the pod without prompt

Testing Style

Light and casual to create natural reactions & blend into conference presentation. Yield to sales team to accommodate sales efforts

Test Structure
  • Initial reaction
  • Implied first action
  • Preferred booking method (mobile vs tablet)
  • Major set-backs that may cause aborting
  • Do they know their booking options and how to search for them?
  • State of user while booking (on phone, rushed, multi-tasking?)
  • What percentage of users were able to successfully book w/o assistance

Tiny tweaks while User testing (cheating?)

When users weren't even recognizing where to begin, I made tweaks to the tablet's first screen during testing until user's could (at the very least) begin the test without prompt correctly. #productmanagementforthewin
Curious participants approach POD

I'd have the personas development organically by only studying those who genuinely attempted to enter pod for a meeting without prompt.

User attempts to book meeting

With the least amount of interference possible, I observe and take note of user attempting to book meeting through attached tablet application or mobile app.

Assistance & qualitative interview

Once user couldn't go any further, I'd interject and assist in booking or entering pod. Once in, I'd get them comfortable and talking about their experience with the goal of filling in any gaps I had in their study.

Resulting Stats

Inspite of the challenges, we took away solid statistical data. There were a few clear take-aways.

1.
if unsuccessful at first pod, users were starting over at a new pod
2.
Email input on 2nd screen caused a lot of strife & four letter words
3.
Lock to sound to screen timing affecting over 80% of users
4.
35% of users left door ajar for heat or fear of being locked in
5.
pods placed in the sun causing greenhouse effect
6.
Basic navigation like next, back and start-over didn't exist and were missed
100%
Every user reported trouble accessing pods in some way
90%
Users at conference mostly used the tablet on the pods over our mobile app to book meetings
30%
Users reported having experienced similar pods that caused confusion with the Zen Space service

Solution

Because business strategy mainly focused around conferences in the near future, the tablet experience became the top priority to improve. I needed to create new wireframes for stakeholders and team to review and discuss.

With much to be desired, we could only implement some basic changes able to be built-out within a single sprint.
Here's what I came up with:
Stakeholder requested clearer indications of the status of the pod. He and I came up with four states, each smart enough to give proper CTA, allowing users to easily kick-off next steps.
Every input from a user requires equal reward. Removing the heavy-handed email input as our second screen, we made the email input optional as a method the user can send themselves their access code after they've successfully booked a pod.
Today you can only book the pod associated to tablet. To accommodate multiple pods at future conferences, I'm also thinking through a kiosk solution where users can book any pod through one tablet application.
Basic back, close & cancel options were added where applicable. In addition, if user enters an incorrect access code into a pod's tablet, the new experience now offers a graceful recovery email with access code.
View Tablet Wireframe on InVision

Conclusion

Despite working with team for the first time, sales taking priority and user testing perhaps not as formal as I'd usually like to go, I do believe in the changes we're taking toward a better product. The biggest change I would have liked to make was to perfect the IOT to tablet feedback and timing. I'd want to work with development teams to ensure users could successfully access their pods without assistance.

Perhaps next sprint!🤞

View Next Case Study

See how I debunked assumptions by creating data-backed personas.
View Persona Case Study Next →