starclinch.com

Redesigning India's biggest Artist and Entertainer booking platform

My role

Sr. Creative Strategist

Duration

4 months

Team

CTO, Product Manager, php Engineer, Graphic Designer, Interns

Skills used

  • User research
  • Visual Design
  • Mockups
  • Wireframes
  • UX Strategy
  • Prototyping
  • Testing

Tools used 

  • Photoshop
  • NinjaMock
  • WordPress
  • WooCommerce
  • CSS
  • php
  • Integromat
  • Zapier

Deliverables

  • mockups
  • style guides
  • webpages
  • site-map

The Problem

StarClinch is India’s biggest Artist & Entertainer booking platform with a lot of A-list Bollywood celebrities onboard. 

Poor products can be a barrier to a company’s success. Any why reinvent the wheel when we can use the best tools available out there to solve our problems?

A lower turnaround time is crucial for customer retention, and a CMS is needed in place for quicker updates to Artist profiles. 

Without a system, it is impossible to give high user satisfaction and get increased revenue. The aim of this project was to redesign the whole online product aiming to improve the UI and UX

Business objective: Get more daily leads, Reduce TAT

Research

User Research (Personas)

When I had joined, StarClinch already had users defined into two types: The Artist, and The Client. 

"The Artist"

”Stage gives me a high – a high stronger than any drug in the world. I want to perform in front of audiences regularly, and earn decent money through those gigs. I an definitely considering to turn my art form into a full time career.”

The Artist. aka The Entertainer or The Talent. 

They are true connoisseurs of their own art form. StarClinch had identified 14 different categories for these artists, and each category had further subcategories. – making the categorization of talent really granular. 

Any new artist that was on-boarded will definitely fit into some sub-category. An Artist is looking out for as many gig opportunities (aka events where they can perform) as possible, and wants to make the maximum money from that gig. That’s why we did see some Artists’ with really inflated performance fee. 

"The Client"

”Shit shit shit shit. My event is coming up in a few days, and I need something to spice it up. I want to book or hire the best talent or performer for my event. I’m in a hurry so tell me fast and keep my budget in mind.

The Clients – the real users of the platform – i.e. the ones who come to the site and submit their event details and what they are looking for. Since they are in a hurry, and need diversity in terms of performers and rates, they probably are submitting their requirements on 10 different event sites simultaneously. 

Subtypes: Event Managers, Corporates, College Campuses, and individual people. 

70% of them come via mobile. Their use case might just be finding and booking the Artist, and most of the time, they themselves might not be in the audience for the actual event – so they want to see the performance of the Artist beforehand maybe via video/audio.

Eg: A company HR that books an Artist for a Product Team cultural dinner. The HR will not be present in the actual performance of the Artist. 

Given these two user types, I as part of their team, probed further into gathering the needs and problems of the Artists and Clients. We read all communication that Artists and Clients were sending us – some of them even had complaints, some had new feature requests. 

We interviewed Artists and Clients on an ad-hoc basis – whenever someone contacted us regarding anything via any medium (mostly email/call), we probed further by asking relevant questions about their problem and took notes. By asking questions like, “Where do you get stuck in the process,” “Walk us through the last time when you booked an Artist,” we were able to nail down user behaviors, needs, and goals and refined the user types mentioned above.

Competition Analysis

I also took a quick look at some of the apps and websites that the team at StarClinch had mentioned:

GigSalad, BookArtisto, PartyMap, EventFAQs, Jilmore – all of them have almost the same functionality as StarClinch.

We needed a differentiating factor

USER FLOWS

User Flow / Customer Journey

User and Information flow. The 3 persona types are highlighted.

I came up with a list of general requirements for a used books marketplace app and started to work through a user flow of buying a used book.

The structure will be like a typical online e-commerce marketplace app, as defined in the next section.

The Buyer would want to check the condition and price of the book, and will make a positive decision if the Seller is geographically closer. The Seller will want to make profit, and ensure that their ad is discoverable to Buyers. 

 

Payment Logistics 

I researched two ways that are tried and tested in the current market: 

  1. Direct peer to peer payment using cash or direct wallet transfer (like OLX users do)
  2. Amazon like escrow payment model, where the marketplace sits as the third party between two parties and withholds/releases payments when goods are delivered.

To keep things simple and to keep focus towards the app experience, I decided to go with option 1. 

 

Delivery Logistics

Once the payment logistics choice was made, the only feasible delivery logistic is that the buyer and seller actually physically meet at a geographically convenient location, and trade the book and payment. The chat interface aids in doing this by presenting short-cut text messages that the user can simply tap and select.

App Flow and Features

App flow for Buyer
App flow for Seller

The above chart shows a tentative app flow and the process by which a buyer can shortlist and buy books, and a seller can post books that they want to sell. 

 

App Features

The structure will be like a typical online e-commerce marketplace app, with screens for – login/signup, onboarding, search page, search results, product collections/categories, product, seller listing, and a chat interface instead of a cart. The app will also have an interface that allows users to post a free ads about a book that they might have to sell.

Rather than showing a gazillion different ads about the same book to the user, the app will have only one product page per book which will list the available sellers for that book on the same screen. The app will show the condition of the book and the price offered for each seller that is selling the same book. This is done to avoid cluttering of the marketplace, and leading the direction of the marketplace towards a book information community. 

Design

The design involved making UIs that improved the overall product UX and strategy. 

Product / Web-app Redesign

The earlier StarClinch was built off on legacy PHP and Microsoft stack. It did not have an efficient CMS for quick updates to profiles and pages, nor did it have the very best of UI elements. Everything was just put together using superglue to make it ‘just-work’. 

The earlier version of StarClinch. It had a single button in the hero section, and showed all the 14 categories of Artists in the form of clickable icons at the bottom of the hero banner.

The earlier StarClinch was built off on legacy PHP and Microsoft stack. It did not have an efficient CMS for quick updates to profiles and pages, nor did it have the very best of UI elements. Everything was just put together using superglue to make it ‘just-work’. 

The redesign. Better CMS allwed drag and drop functionality for build web-pages, and had better UI elements. Pictured here, we see the search bar and just the top 5 Artist categories linked below that.

My philosophy is “Why reinvent the wheel?”.

I showed the team how an off-the-shelf CMS can be a better alternative for the overall product strategy. The CMS was a popular PHP based CMS which allwed speedy updated to Artist profiles, and pages on the website. It also automated handling the SEO. 

Reducing Turn-Around-Time

StarClinch was using email as a method of communication with Clients and Artists. It had a really poor turn around time of 48 hours. Sometimes the delays were caused at StarClinch business team’s end, but most of the time it was at the Client end. This was due to delayed initial response from StarClinch. The Clients submit their query at multiple platforms and websites and the one which reaches out to them first, is the winner in closing the deal. 

To improve the TAT, we designed an interface that allows Clients to shortlist suggested artists quickly, without the hassle of going through long chains of email. 

Make it easy to Capture Leads

StarClinch was using a traditional form coded in jQuery to capture leads. The design was not responsive, 2005-ish, and animations were sluggish. Sometimes, on slow mobile data connections, it used to hang up while on the submit screen. This was resulting in drop-offs and missed leads. 

I designed and coded a new form interface which was light weight (faster 1st paint, and load times), responsive (usable on any device screen size), and visually looked minimal and clean (improved UX).

We replaced this form with a conversational chat-bot for more than a week, but it did not go as planned.

Artist Availability Calendar

StarClinch was manually contacting Artists for their availability and rate every time a new Client query used to come in. This was a huge effort on the small in-house business team that they had, and resulted in bad TAT to Clients (in case the Artist wasn’t immediately available to take their call).

To solve this I came up with a simple responsive form that Artists can use to pre-fill their availability, rates and other important information. Artists could fill the dates that they are available till the next 6 months. 

These were the basic point-of-contacts that helped improve the product performance and experience. 

RESULTS

Before Redesign

1
LEADS / DAY
1 hrs
TURNAROUND TIME
1 k
MONTHLY TRAFFIC

After Redesign

1 +
LEADS / DAY
1 hrs
TURNAROUND TIME
1 k
MONTHLY TRAFFIC

Conclusion

Next Steps

Next steps would be to test again and see how these concepts fare in the hands of more users. Testing for success and efficiency would be a usability test, which could measure how long it would take for Clients to complete the whole booking process.

Next iterations would also work through more edge cases. Some examples:

  1. UI tweaks. Refining the colors, fonts and layouts of elements. Some design decisions were made in haste, because the team wanted the product live as soon as possible. UI customizations will need to be done on top of the existing CMS theme via CSS. 
  2. Better Filters. More research and testing on UI patterns for Filter interface on the browse page. How can we better enable Clients so that they find the Artist within their criteria? 

Thank you for patiently reading!

Your email stays private. Privacy Policy.