Shaping User Experience at Zivame: A Product Management Case Study

This is a Guest Blog by Udit Khandelwal. You can read more articles by Udit.

blog-set_article-header-840-x-575-copy-1

“The website is amazing and the session was awesome! I would love to come back for another round!” –Deepika called out while leaving for home after going through a usability testing session at Zivame. From that moment, Zivame was always going be the first choice for Deepika – a proud homemaker and entrepreneur.

What did we do to invoke such surreal emotions in people who shop with us?

Well, we involved users at each and every step of product design. In my article How I Changed The Way Women Buy Bras Online I covered how we leveraged user research to discover a new way of shopping for bras. Here, I am going to walk you through the journey wherein we managed to test the design with real users, obtained real insights and implemented course correction.

The Game Plan

Challenge

The resources were limited, the scope was huge and we had to keep churning incrementally enhanced designs.

Endeavour

The entire website was supposed to be designed and developed from scratch within 5 months. The last month was already reserved for all the testing, deployment and stability related activities. So we had no more than 120 days to design and develop the new Zivame experience. I had heard this saying somewhere:

No shortcuts today; I’m in a hurry – Swiss saying

… and I thought, it was just the right time to follow it. We needed a game plan that involved no shortcuts because we couldn’t afford to go down the wrong lane. Hence, we decided to do the following after our early research was over:

design-cycle-v22x

 

  • Lo-Fi Prototypes: Refine the sketches until we were done discovering the loopholes and until we had fixed all the broken flows.
  • Formative Tests: Use paper prototypes to test with whoever you could,whenever you could, even if it was on the lunch table.
  • Hi-Fi Prototypes: Develop a high fidelity interactive prototype, as close to the final product as possible.
  • Summative Tests: Test it with real users and obtain real insights.
  • Beta Tests: One final round of testing, on the actual product, before we handed it over to the world.
  • Iterations: Every test delivered some good news and some bad news (which was good news). We had to prioritize fixing bugs and making enhancements for every iteration.

Lesson

Usability testing is an ongoing activity that needs proper planning, time and resources.

Suggested Reading

User-Centered Design Process Map – usability.gov

Formative Tests

Challenge

The initial design was completely untested and development teams were waiting on us. We had to give them something solid, real quick.

Endeavour

Low fidelity prototypes work beautifully when you want to fail faster. They help you discover flaws in design at an early stage and designers themselves are very open to making changes in the raw design. We did the same at Zivame. Once we were done with white-boarding, we quickly moved on to our tools to create different screens on the computer and took prints to create screen flows.

img_1318

And then, we simply asked some folks from within the office (who closely matched our target persona Mahi Agarwal) to perform certain scenarios. Whenever they were stuck even for a bit, we knew there was a problem. More than often, they would even give us suggestions, which we took note of. We would then come back and discuss why the users were suggesting what they were, go to the root cause of the problem, and figure our own solution.

Sometimes tests not only tell you what’s wrong with design, but they also reveal new opportunities. For example, it was during the formative tests we discovered that users were able to comprehend and interact with notifications. We took that as a green signal and design for a stronger, deeper integration of notifications.

Lesson

For testing, don’t wait for the final product; go ahead with whatever prototype you can afford and test with whoever you can find. Fail faster.

Suggested Reading

The Skeptic’s Guide To Low-Fidelity Prototyping – Laura Busche, Smashing Magazine

High Fidelity Prototypes

Challenge

The website had more than 300 unique screens and screen-states. Putting together a click-through was a mammoth task.

Endeavor

We first set our goals and non-goals before building the prototype. This helped us reduce the scope of prototyping. eg. We wanted to test the new shop-by-experience feature, but were pretty sure we had followed best practices for the checkout, so we decided not to focus on that flow.

Next, we evaluated 3 options for building the prototype:

  1. Flash – my personal favorite, I know I sound old-school!
  2. Marvel App – because everyone is going this way.
  3. Invision App – Marvel’s competitor.

Now Flash was quickly ruled out because of the overheads involved. Marvel kind of worked, but had limited support for overlays, and my entire design was based on surfaces and overlays. Invision offered me better flexibility, so I went ahead with Invision. Here is the Zivame New Stack Prototype that we used for usability testing.

home-proto

Lesson

Scoping is critical; even for a prototype.

Suggested Browsing

A tour of Invision App

Summative Tests

Challenge

The test had to be optimized to FAIL the design.

Endeavour

We decided to write down the script that we were going to use during the usability testing sessions. The critical piece here was to figure out exactly what to test and how. So I listed down my goals and non-goals, based on which I broadly figured out what was I going to test.

  1. Initial Mental Model – Expectancy Test
  2. Actual Usage – Free Exploration Test
  3. Navigation – Performance Test
  4. Affordance – Visual Affordance Test
  5. Task Flow – Performance Test
  6. Sentiment – Semantic Differential Process

Once that was done, I quickly mapped a technique against each line item and then moved on to the modules that I wanted to focus on. After this I moved on to defining the task-flow of individual scenarios. I didn’t write down the language of the scenarios as I din’t want to sound stiff. I have shared the script below on Slideshare.


Lesson

Use hammer for the nails, but screw-driver for the screws.

Further Learning

Consider taking Practical Usability Testing course from HFI.

Recruitment

Challenge

Finding women (in India) who’d agree to participate in the testing of a Lingerie website.

Endeavour

We wanted women who closely resembled Zivame’s target persona Mahi Agarwal. We took to social media and made an announcement. We asked women to help Zivame in building a great shopping experience for women! A lot of women came forward and we received a good number of responses. Not only this, they also invited their friends to participate. And kudos to forward-thinking women like Deepika, Subha and Aastha, who went a step further and agreed to put a face to our participants.

persona-v2

deepika-bw
Deepika, Entrepreneur & Homemaker
subha-bw
Subha, Blogger at dolphindives.in
aastha-bw
Aastha Chaudhary, Homemaker

We were in a good position to screen and recruit our participants. Women who expressed interest, had to fill the participant recruitment form. After a quick screening, we shortlisted the participants and gave them a call to schedule the session with them.

Lesson

Finding real users isn’t that difficult. You just have to do it the right way!

Suggested Reading

Dragonfly Effect, Jennifer Aaker & Andy Smith

Usability Test Sessions

Challenge

Talking to women about a website that sells bras.

Endeavour

On the D-day, we were well prepared with systems set up, printed copies of the script, the team was ready to perform their roles and the participants were to be greeted warmly.

We started the sessions by making the participants feel comfortable. We began with some chit chat and brief introductions. We emphasised how important their contribution was and asked them to not worry about hurting our feelings and give honest feedback. In order to avoid them sharing their bra size details with us, we made sure we told them to assume their size was 34C. I think they liked the idea. We made sure they believed:

You are not being tested, we are!

Invariably, every user would smile at this moment, and we knew, we had managed to make them comfortable. Throughout the session, we made sure, the focus was on the tasks (and hence on design) and not on the products.  That’s when we would begin the flow (as mentioned in the PPT).

We discovered some pretty interesting things during these tests. To our surprise, none of the users had trouble figuring the ‘shop’ menu, which was a big change from our previous design. However, users were confused when they reached the sub-menu and we knew it needed to be simplified (which we did later).

We also discovered a basic issue with title bars of our surfaces. Users were facing difficulty going back and closing the surfaces. Again, we resolved this issue in our next iteration.

One of the key findings was about the sticky buttons at the bottom of the surfaces. We realised that sometimes the button used to break the user flow as users were clicking on it without reading the labels or they were misinterpreting the labels. We found alternates to such situations.

All in all, the users proved to be very helpful!

Lesson

Users are humans, if you treat them well, they will be very helpful.

Suggested Reading

Rocket Surgery Made Easy, Steve Krug

Test Script by Steve Krug – sensible.com

The Bug Bash

Challenge

We needed to make sure if the final product was behaving as designed and intended, and we were running out of time!

Endeavour

There is always a fair degree of difference between the actual product and the implementation.

When the Zivame beta product website was ready, we wanted to make sure that the product was behaving as expected. We wanted to see if users were comfortable interacting with the UI controls we had implemented and wanted to see it working in the real world.

So, we opened it up for all the Zivame employees, and conducted a 3 hour bug-logging Marathon, which we called Bug Bash. We issued a coupon that would work only on the beta website for 3 hours and asked all the employees to make use of the coupon and log whatever bug that they faced in the Bug Bash Form.

We divided them into different teams and announced prizes for the top 3 teams. The plan worked and we received 223 responses from different teams. It took us 2 days to go through the entire list and figure which ones were genuine. Most of the bugs filed were duplicate or known issues, but we discovered 12 new bugs (of which 3 were related to UI).

This gave us a high degree of confidence to release the beta externally!

bug-bash-report
Zivame Bug Bash Responses

Lesson

Testing never hurts and it can be done at any stage.

Kudos to the women, who helped us all along the way in building such a fantastic shopping experience at Zivame!

Resources

 

Have any challenging experiences to share as a product manager yourself? Or something you found extremely interesting in this post? Comment below and let us know.

Waiting to drive such game-changing product experiences yourself? Don’t wait any longer. Enroll in the UpGrad Product Management Program now!

The following two tabs change content below.
Udit Khandelwal
Udit is UX Director at Zivame. He has had extensive experience within the UX space while at Kaseya and Cisco, as well. Like any true expert, Udit writes about his learnings and ideas at notuser.com. Udit is based in Bangalore.