Case Study: USER TESTING at the outbound location with several outbound users

Samath Aravinda
4 min readJan 8, 2020

I can’t mention about the company/product names or any designs. This is mainly to showcase of process we go through and ups and downs we face.

Overview of Product

This is a TASK MANAGING application and the target was that we have to implement the new feature into the existing application.


Immediately (less than 3 months) we have to release this new feature to start marketing for this application, this new feature is a turning point and the big revenue model of the application as well

  • Keep the existing users' momentum
  • Most of the users from different outbound and new feature are the marketing point for new customers
  • How to notify about the new feature
  • Timeline

Road Map & Members on this workshop

User personas → Wireframing→ Journey map/flow test → Prototyping→ USER TESTING → Final decision for the task and time frames

TEAM: My self and UX Lead from outbound and the product owner.

User Personas

I, having brains-tome with the PO and we manage to identify on main user groups and came up with user-persons that mainly who use this new feature,

This is only to showcase see how was our workshop walls.

Wire-frames we did on several paths,

Case 1: Adding some components into a related existing page to do the purpose of the new feature

Case 2: Creating a completely new section for the new feature

Case 3: How willnew feature notifications fit in


We on a thought process on this mainly considering existing users' momentum /behavior on the related pages. Limited time-frame we have to implement.

After several Wire-frames and A/B testing, we finalize one design for the user testing, which adds some new elements to the existing related page that covers the purpose of the new feature without affecting any other user-flows.

In this situation, the plus point we had is the HTML prototype version of the existing page, so our effort is less on implementing the new elements and the time we put for implement is really low.

Same time we have to think about the actual data as well, when we are engaging with the existing users and when we plan to implement a feature on related existing page we have to come up with the actual data and the connection data should be accurate for the users to do a proper user testing for better results. (As a good practice we have to use actual data for better user testing)


Here our main purpose was to introduce the new feature with targeting our user personas and do some UX matrix and find out if there any flow change we can change or create newly to give this feature main priority.

Also, we gave second priority to timelines, development barres with existing languages, existing UI components.

As mentioned earlier we came up with several ideas and derive into the final low fiddly combining a lot of ideas from different low fidelity from dot voting on. (Good read for dot voting )

Case 3

The above two cases need to introduce to the user so we came up with options that how we should indicate notifications and at the same time how we give the user guides. while we go-through low fidelity wire-frames for this we understood that this may need frequently when we introduce new features or any upcoming critical message. so we decide to make this as the common component that can be used for other future details

User Testing Preparations

  • We got ready with the high fidelity wire-frame for the above 3 cases.
  • Got ready with the script for users according to the cases
  • Create a script that fit into 15 minutes with different languages according to the user testing profile
  • Test out the screen recording with a trial
  • The moderator role is done by outbound UX Designer because of the language and I’m the observer. But we both ask questions after the user testing script is over.

User Testing Result summary

  • Most of the users preferred and positive feedback with case 2.
  • On the user test, we ask about if we launch the case1 option first and if we switch to case 2 option it’s that fine. Almost all agreed for that because they need the feature sooner and case 1 is aligned with existing product (according to existing users ) it was fine for them. New users preferred case 2.

Decision meeting with the Product Owner and UX team

  • Agreed on the Case 2 high fidelity wire-frame is the best option for this feature and finalize on timelines
  • Until the case 2 feature develops decided to take a high-speed approach to release the case 1 option for the existing users and for the marketing team can start on there duty about this feature.

Unaccepted thing happens

When creating the User testing script we consider the profile and we create with the language of the user to make them comfortable. But the unaccepted thing is at some point users express their thoughts from own language and as an observer could not understand, We manage to understand those because our team had different language people. So as a step after this incident we got ready with voice translator to text option activated while we conducting the other user tests.

Thanks For the Read…