How we adopted and implemented the Slide-to-Pay button

We recently made changes to our payment flow, allowing users to pay directly from their cart with their top payment methods pre-selected. And while this change might appear to be on the subtle side, don’t be fooled into thinking these are just small tweaks. We’ve been finessing this valuable bit to unlock convenience for our users and drive business growth.

But why did we invest in this when it seemed like the payment process was already solved? Well, moving from the cart page to the payment page required users to make several decisions. Although they mostly chose their preferred payment method, they were unnecessarily exposed to other options. This led to drop-offs in the user journey, as more decision-making often results in higher abandonment rates at the end of the funnel.

These compelling reasons motivated us to invest in a quick checkout experience. So, we embarked on finding the perfect solution. To enable quick checkout on the cart, we needed to showcase relevant payment information, provide an option to change method, display the final amount, and, of course, include a payment button.

Evaluating the pay button

Now, let’s talk about that payment button! We often can think of buttons as any other UI component defined in the design system. But this was no ordinary UI component; it was a super important gateway for users to become customers. To re-emphasise this button was going to be interacted by 2–3 million users every single day. We carefully considered the button interaction, weighing two options: a simple tap or a slide.

While a tap seemed familiar and straightforward, we were concerned about accidental taps due to button blindness. On the other hand, a slide offered a more intentional interaction, introducing a touch of ‘healthy friction' to break users’ blind tapping habit.

Even though the design team was more inclined towards the slider we initially went with the tap button. Since product stakeholders had concerns around the complexity and friction slider would introduce and also slider required higher development efforts.

Quick checkout being a big shift in the user journey, we released it in controlled experiments and followed a process of analysing experiment data and iterating.

Data reads

Positive trend: We observed a significant increase in conversion, indicating that more users were successfully placing their orders with the new flow. It proved that there was a clear need for quick checkout.

Negative trend: However, some users were dropping off after tapping the pay button, failing to complete payment authentication

Users were not noticing the new pay button and accidentally tapping only to realise later.

While the new UX was a success overall, we didn’t settle for half-baked solutions. We brainstormed to understand the cause of the negative trend. Our first attempt focused on making the tap button more noticeable through tooltips, shimmer animation, and copy changes. But despite our efforts, the negative trend persisted. That’s when we decided to build the slider button, getting all stakeholders on board.

Building Slide-to-pay

Now that we got stakeholders alignment we made sure to define the slide button meticulously. We thought of every aspect of how our users would be interacting with the slider. One of the major concerns that stakeholders had was that it might lead to a drop in conversion as the fear was that users might not be able to comprehend the slide interaction. To address this, we took various measures:

Educating with hinting

One straightforward way of educating users about a new experience is using tooltips, which we did. A secondary more smarter way is hinting. Hinting is a way to subtly educate the users on how they are supposed to interact. The way we thought about hinting was not from a first time experience but as a part of the core UX.

Hint #1: On each page load, the slider bounced to the right, accompanied by a shimmer effect, indicating the intended action that needs to be taken.

Hint #2: If a user tapped on the slider than meant that they wanted to complete the action and pay. So to capture this intent and guide the users the slider bounces to right indicating the interaction that is needed to complete the action.

Tweaking the completion point

Typically, a slide interaction is considered complete when the slider reaches the end point. At Swiggy, for instance, we implemented a similar slider a few years back and learned that users didn’t slide to 100% and left the slider midway. So learning from the past we instead defined the completion area at 70%.

We also added a couple of signifiers to indicate the state change here; the double chevron inside the circle turns into a checkmark and a subtle haptic feedback is triggered

Comfortable touch area

We ensured that the tap area of the slider was larger than its visible footprint, allowing users to interact comfortably.

With these measures in place, we were ready to experiment with the slider button for our quick checkout UX.

And voila! 🎉 Upon analysis of data it was clear the slider button added healthy friction to avoid accidental taps without affecting overall user conversation. Now, quick checkout with a slide-to-pay interaction is live for all our Swiggy users.

Key Takeaways

1. Contextualise: As product people when we think of friction it does not generate a positive emotion. But like everything else right amount of friction depending on the context can play a positive or negative role in the UX. In the case of the slider, it provided “healthy friction” that improved the user experience.
2. Obsess: We addressed concerns around the complexity of slider interaction by obsessing over the details. We carefully designed hints and signals to make our users’ lives easier.
3. Persist: From the very beginning, we had a strong conviction about the slider button. Throughout the iterative process, we passionately advocated for its value and consistently highlighted how it could solve the challenges our users were experiencing. In the end, our instincts proved to be right, and we implemented the slider button.

We hope you enjoyed reading about our journey! If you found it helpful, leave a clap 👏🏻

Feel free to share your feedback and thoughts in the comments or reach out to me directly on Twitter @sanyamjain_ or via email at sanyamjain18@gmail.com.

Healthy friction in UX was originally published in Swiggy Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing with constraints — Live Activity and Dynamic Island

Apple launched the Live Activity widget with iOS 14 and followed it up with Dynamic Island in iPhone 14 Pro. With these updates, Apple attempts to reinvent push notifications delivery on mobile devices. On it’s launch, it was instantly obvious that Swiggy, a food delivery app which sends multiple notifications to communicate delivery progress, has the perfect use case to utilise these new features. Fast forward to now, both are live for Swiggy users 🎉

We were awestruck by the Apple’s slick demo but as we dug deeper we realised that there’s more than what meets the eye. This blog is behind-the-scenes of how we went about designing the latest widgets for our users.

Why Swiggy is the perfect use case?

Being a hyper-local food delivery app, post-order tracking is a critical part of users' journey. After a user places a food order, these are the following states that we communicate to keep them updated on the order’s progress:

1. Order received/accepted by restaurant.
2. Restaurant is preparing the order.
3. Delivery partner has reached the restaurant.
4. Order is out for delivery.
5. Delivery partner has reached the user’s location.
6. Order delivered.

The above steps all take place within a span of 30 – 40 mins. And to keep the user informed we send 5 notifications vs with the live activity widget all of the updates can be handled in a single widget! It was clear that Swiggy users could get immense value out of the live activity framework.

What is Live Activity?

Let’s start with some context on what is live activity —

This is how Apple describes the widget — A Live Activity displays up-to-date information from your app, allowing people to view the progress of events or tasks at a glance. You can read up the HIG guidelines for more information.

It is a smart way of surfacing live updates for any activity which happens in a short span of time on your device. Some of the use cases include cab rides, flight tracking, and sports updates. Live activity solves the following things:

• Avoids crowding of push notifications.
• Chunks information in a reliable and glanceable manner.

Dynamic Island

Later in the year, Apple introduced Dynamic Island on its iPhone 14 Pro. It’s a pill-shaped cutout at the top of the device which can be used to share the status of any live event when the device is being actively used. The most common use-case includes song status from any music app, stopwatch/ countdown, or toggles for screen recording.

In reality, it is an extension of the Live Activity widget which neatly ties the experience together when the user is actively using the device.

This is how Apple describes the island — On devices that support the Dynamic Island, the system displays Live Activities in a persistent location around the TrueDepth camera. You can read up the HIG guidelines for more information.

So one of the important things was to ensure consistency with the already designed Live Activity widget along with of course our app.

Now, let’s get started…

Live activity and Dynamic Island both are rather simple frameworks with limited scope and complexity, which is what makes them so good! A bigger part of designing for them is working around the constraints, so as part of describing the process I will be talking about the different constraints and how they shaped the designs.

Since we were super enthusiastic and wanted to be early adopters of the feature we began the hands-on work the next day of release. That meant that a lot of documentation describing the constraints was not yet available for reference. Over here, kind folks at Apple stepped in to help us and after multiple back and forth emails and calls with their DevRel we got the clarity we needed. So let’s get started

In many places the following abbreviations have been used, LA for Live Activity and DI for Dynamic Island

Interval of receiving an update can be high

The frequency of receiving an update can vary and sometimes be on the higher side. This can be due to different technical and operational reasons.

This meant that an approach that leans heavily on the progress bar or the map might not be the best. The user might see the progress bar not being updated for a while which may lead to unnecessary anxiety. So we didn’t want the users to anchor too much to the progress bar or the ETA number and to solve for that we introduced a third element, illustrations.

Instead of making the progress bar or title with ETA the primary hero element (like above) we chose to leverage our illustration style. With the illustrations we were able to strike a balance, as the progress bar and ETA, while still prominent, didn’t have the highest visual hierarchy. The illustrations accurately communicated the order status without being too specific. Illustrations also solved perfectly for glanceability which is one of the primary goals of the widget.

At Swiggy our visual team has been continuously evolving the illustration style introducing 3D characters as part of that. Going forward you can expect to see more 3D being part of our visual communication :)

Making sure LA works with all kinds of backgrounds

LA will show up on the lock screen, and how a user chooses to customize their lock screen is not in our control so when choosing a background style for the widget we had to make sure it looks the best with all the kinds of backgrounds. This restricted our choices and we ended up going with a mostly solid black background with a slightly reducing gradient from top to bottom.

How many pixels can be used on the Dynamic Island?

While designing we had to navigate through some ambiguity and we still don’t know how many exact pixels can be used up on the dynamic island. HIG attempts to answer some of these questions but there still remain grey areas. The island can expand a bit in shape in all the views which means that the pixels available are not limited to the actual size of the cutout.

The larger question was how to use the limited space to best communicate the order status and this is how we went about the different presentations:

For compact: the left side shows the icon indicating the order status and the right side will show the ETA

For minimal: the pill shows the icon indicating the order status

For extended: straightforward and should be the same as live activity widget for consistency. The only adjustments needed were to accommodate the camera notch.

One of the things to highlight here is the picking and tweaking of icons, the icons were crucial as by themselves they had to convey the order status. The advantage we had was that icons are already part of a user's journey on Swiggy so they are most familiar with the icons we were going to use. The only thing to make sure of was the same icons work on the small space on DI.

An interesting example of tweaking an icon was the bowl icon which was going to convey that the food is being prepared state. The original icon part of our system worked well in larger sizes with supporting text but didn’t work out on DI. The icon was too intricate with details too small and too close to each other. Adding a little flourish to the spoon and increasing size of circular elements (representing food) instantly made the icon more comprehensible.

Lack of animation support

We had started with plans to include subtle animations for added delight in different order states but had to scrap those ideas and stick to static designs. Although we do see some simple animations for Apple features there is no support yet for any kind of animation for third party on both LA and DI. The reason mentioned by Apple was the drainage of the battery that continuously looping animations can have.

Font of course can’t be customised

Honestly, this was expected. Looking at the precedent set earlier for home screen widgets Apple once again stuck to the default system font. Although as a designer at Swiggy, I want all touch-points to carry the same font for our users I also understand that from a system level, it does not make sense. This can easily be abused by product builders and will result in a poor experience for iOS users.

Conclusion

As designers Milan and I faced constraints in various forms, such as limited resources, time, or other limitations as mentioned earlier. However, designing with constraints can be an enriching learning experience, as it helped us develop adaptability and flexibility. While designing it can be frustrating but the trick is to produce the best output despite all challenges and that is what design is all about. In the end, the love of the users will make all the effort worthwhile.

Going forward

One of the most interesting observation from the project was how the whole of order tracking could be folded into such a minimal experience. Literally, a 24px icon is able to successfully communicate the order status. Going forward we certainly see our approach to in-app order tracking being shaped by some of the insights we gained from the new widgets. Apart from that from a support point of view we plan to —

1. Add support for InstaMart and all other services on Swiggy as well.
2. Include a visual cue to differentiate the widgets in case of multiple simultaneous orders.

Want to get say hi? Send me an email at sanyamjain18@gmail.com or tweet @sanyamjain_

Designing with constraints | Live Activity and Dynamic Island was originally published in Swiggy Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Singapore living up to its reputation as an innovation hub found a smarter way to showcase discounted items. Even after a month of visiting the country it has stayed with me, instead of the Marina Bay Sand, Super Trees or the world’s best (mall) airport.

So what’s so special about the way they showcase discounted items? Honestly, there is nothing groundbreaking here, it is basic colour coding. Stores pre-define the discounts into slabs and each of these slabs has a corresponding colour, for example, 15% off is marked in blue colour. This slab information is printed in form of a chart and placed around the store. Based on these colour codes, stickers are attached to item labels. So when shoppers browse they can figure out the discounted price from the sticker.

I found this approach shopper-friendly, environmentally conscious, cost-efficient, uniform and flexible. Sounds a bit much for a simple solution? Let’s break this down.

Environmentally Conscious

There are millions of special labels printed just for the purpose of discount. All the extra paper, processing that takes place each season might not be the biggest waste source but the Singapore approach can help minimise the wastage. Take the holiday season for example when stores across categories place their items on sale, all those extra labels that get printed can be done without!

Cost Efficient

There are two ways in which extra cost is being reduced — One is the obvious one where the label printing and processing gets cut down. Second is the labour cost, all the time spend on attaching the tags to each item would require hours if not days of extra effort by the store staff whereas this pasting of stickers is much quicker.

Uniformity

The reason why I’m writing this article in the context of Singapore is because the colour coding was found across the city stores. The framework not being restricted to a store is what makes it super useful as it creates a mental model. Apart from that, uniformity helps in other ways:

• Just by referring to the discount chart the shopper knows the kinds of discounts that exist in the store.
• There is no need to hunt for the slashed price on the label, a quick glance to register the sticker colour is enough.
• The system indirectly ensures that stores don’t have too many slabs or odd slabs like 13% or 42%. As more slabs mean more colour stickers would be required which can confuse the shopper.

Flexible

Item stickers instead of being colour coded could have directly indicated the % discount, like a 50% discount off an item, right? That even reduces one step as the shopper does not need to look at any chart. But the problem with that is it’s not flexible, if the store wants to increase the discount on some item then they need to reapply the stickers. This changing of stickers can be a lot of manual work depending on the change. Instead with the colour-coded framework the store manager can just edit the chart and boom all the store items with the corresponding colour are now at 50% and not 40%!

The above factors combined is what makes this an exceptional solution. But is this scalable? This could be a nightmare for shoppers who are not comfortable with basic maths! Perhaps this can work only in countries with higher literacy rates? I’m not too sure, what do you think? Does your country do it in a different way, would love to hear. Do let me know.

Overall it’s a simple optimisation but still so smart, when I heard of Singapore’s reputation as an innovative city this was certainly not the area of innovation I expected. Singapore truly surprised me. Makes me think there must so be many everyday experience which can be improved with some intentional thinking!

If you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet @sanyamjain_

Do you, like all of us, dread clicking the gear icon? Does it make you feel dumb to find anything at all in settings? If yes, then who is to blame here? It is we, the designers!

For far too long settings have been reduced as an afterthought when designing products. A google search on the subject barely returns any useful content. To shake this up and make all of our life easier, I in this case study have documented my process of designing settings for a B2B product.

Project Background

Graphy has acquired Spayee the market leader in India in CBC courses. Since the merger, the design team has been tasked with redesigning the Spayee product. As a part of this effort, settings are to be redesigned.

Being a feature-rich B2B product the current settings over time became too complex to achieve anything at all. In fact, it came to a point where even for simple config changes users were dialing up the support team. 🤬

With this redesign, we wanted to enable the users to achieve desired changes within minutes! 😄

Project brief: Redesigning the settings section to make it user-friendly with a reliable and scalable framework.

Design timeline: ~1 week

Team: Sanyam Jain (Designer), Vishant Batta (Product Manager), and Abhishek Damodara (Design Manager)

Defining key pain points

Most of the problems contributing to an overwhelming settings experience can be categorized into 4 groups:

1. Lack of discovery of all the configs that existed in the product.
2. Lack of easy navigation to a specific config user might be looking for.
3. Lack of understanding of what a certain config means and the implications changing it can have.
4. Lack of scalable framework to accommodate ever-expanding features with their corresponding configurations.

Setting out to solve 😉

I. Adding buckets…

Buckets are adding a level of obvious filtering for the user. It allows easy navigation to the relevant settings. Another advantage of bucketing is adding icons and helper text for additional context to the user. The current Spayee product settings is loosely bucketed into 6 categories: Domain, Payments, Security, Email, Custom Fields, and Miscellaneous.

We #1, combed through all configs and

1. divided payment into two buckets, payment integration & invoice. The payment integration bucket contains gateway setup and country-specific pricing. The invoice contains creating invoice templates and management of invoices.
2. removed miscellaneous to create user experience and permission for all experience level changes and live class to handle the management of zoom and other live class solutions.

#2, categorized buckets further into two groups:

1. Website management: Containing domains, security, payments integration, Email communication, and invoices
2. User experience: User experience and permission, live class

and
finally, #3 added icons and relevant copy to each bucket

Adding buckets contributed to solving all pain points. Bingo!! 🎰

II. Coming up with a layout…

Laying all the configs in a neat and orderly manner was imperative for the best user experience. The current design was a two-column card-based layout. There were some obvious fixes that could have been done to improve the experience but we took this opportunity to think from the ground up.

Key expectations from the upcoming layout:

• Crisp overview for the user so they can easily scan through sections.
• Accounting for labels, helper text, and its control/input.
• Scalable enough to easily add config in the future without input from the design team.
• Flexible to not break in case a unique kind of config control is added.
• Clean with plenty of whitespaces to deal with information overload.

Now, let's start with the explorations 🏃🏻

I researched how other products go about the layout. Inspiration was taken from consumers as well as complex SaaS products. I did not want to confine my research to like-for-like products as that often results in a lack of innovation.

Ideating layouts

I explored multiple layouts to find the one that fits best and to help with the decision-making process I defined four parameters:

1. Ease to scan through the layout
2. Levels of hierarchy that can be cleanly created
3. Real estate needed to place layout efficiently (essential if it needs to fit in a side panel)
4. Flexible to accomadate complex configs

To make this a bit fun, I will be scoring the layout on a scale of 1-5 on each of the above parameters. Below are the explorations for layout –

🔍 Single column layout:

• Scores low on ease of scan, the reason it being a single column layout. This could have been solved with high contrast and hierarchy but inherently a single column layout scores low.
• Adding hierarchy can get messy as all are in a single column. Especially in case, we need multiple levels of hierarchy.

• Scores high on real estate required meaning it can be easily squeezed into limited space.
• The lack of rigid structure enables flexibility to add all sorts of complex operations.

🔍 Single column card layout:

• The card-based layout increases the ease of scan as it helps in guiding the user's focus.
• Adding cards to the layout does not affect the adding hierarchy much.

• The extra margins required for a card-based layout mean more real estate required. Hence, a lower score.
• Scores are similar in the flexibility of adding complex configs.

🏆 Two column layout:

• Inherently a two column layout is much easier to scan through. The left column is read-only with config labels while the right column is with config operations.
• Hierarchy can be added using indentation and styles. The two column layout means added hierarchy is much more effective.

• The real estate required score is low for obvious reasons of two columns needed.
• Adding operation requires a bit more thought and effort compared to a single column. Hence, lower flexibility.

Winner 🎉

Two column layout was picked as the most suitable option with its high score on ease of scanning and hierarchy. The reason for prioritising the first two parameters is that they contribute most to solving the pain points.

Once the layout was final, all the essential components that exist in a settings page were added. Below is the manifestation of the selected layout with all the components placed –

III. Defining interface and its interaction…

The current interface was a simple tab-based interface. Although simple to use there were the following limitations with the current tab based pattern:

• Adding helper copy for additional context was not possible.
• Limited scalability as the design will break if there are too many tabs.
• The first tab is always pre-selected which creates an unnecessary hierarchy

To address all the above concerns and come up with a full-proof solution we explored different interfaces to navigate.

🔍 Exploration 1:

Choose a bucket from page → Bucket opens on a new page

Pros:
- focused and clean navigation
- complete real estate to layout dense information and configuration

Cons:
- friction to quickly switch between different buckets
- possible loss of context when switching user

Pattern can be found in operation system settings. (think macOS and windows system setting)

🔍 Exploration 2:

Choose a bucket from the page → Selected bucket opens in a floating side panel

Pros:
- reduced friction to switch as it allows users to switch buckets without changing of page
- focused on the selected bucket as everything else is blurred out

Cons:
- constant transition to switch between buckets in the short intervals can be disturning
- lack of visibility of other buckets when any bucket is selected

🔍 Exploration 3

Choose a bucket from the page → Selected bucket opens in a fixed side panel

Pros:
- clean layout on the first click of settings easing the decision making of the user
- always visible buckets meant easy switching

Cons:
- intense transition on first bucket selection
- cannot preserve the last selected bucket state

Sanyam on Twitter: "Having spent much time dealing with panel-based interfaces, I found @craftdocsapp approach interesting. 🪟It's impressively intuitive despite not being a common pattern 👏🍨 @danielkorpai pic.twitter.com/XnxGQpYre5 / Twitter"

Having spent much time dealing with panel-based interfaces, I found @craftdocsapp approach interesting. 🪟It's impressively intuitive despite not being a common pattern 👏🍨 @danielkorpai pic.twitter.com/XnxGQpYre5

🏆 Exploration 4

Choose buckets from the page → Selected bucket opens in the right panel

Pros
- always visible buckets which means easy context switching
- optimised for first user experience
- common pattern for settings in complex products

Cons
- information-heavy, too much to look at first glance
- on smaller screen sizes the list of buckets panel will require a scroll

Winner 🎉

Out of the four explorations, the last two clearly stood out as the best. But we decided to go with the 4th exploration. The reason is the familiarity of this pattern with the user along with the other advantages listed above.

At the time we all favoured the 4th exploration but in hindsight while compiling this case study I feel even the 3rd one should have worked. The fact that that there wasn’t a strong enough reason to go ahead with it tilted us to a familiar pattern.

Sigh!! this was all about architecting the interface for settings. 😮‍💨

IV. Concluding thoughts

The process of intensive exploration helped build confidence around the end solution. It might have taken slightly more time but now that the architecture is set, we can go all out designing individual settings. Also, now that we have a pattern for two-panel navigation it can be easily applied to other parts of the product.

Personally, upon being given the task to redesign settings I felt overwhelmed by how I’m going to find the motivation to execute a not-so-exciting project. But as it turned out I enjoyed and proactively worked on it. It remains one of the projects which I and my team are super proud about!

Dropping some more screenshots :)

If you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet @sanyamjain_

It is that time of the year again when we are all bombarded with constant reminders (or pestering) from HR to write our self-review. It might be quite uncomfortable to write it for some (holier-than-thou attitude at play here hehe) while the rest of us are just too lazy to get off our asses to document the shit tone of work and progress we have showcased in the past year. Whatever may be the reason, avoiding it is not an option. So better ace it to justify asking for that exponential raise 🤑

Throughout the year, I maintained closing documents. I write one after each project completion where I like to write my thoughts about what went right, what could have been done better, what were my takeaways, and what parts of it weren’t so glamorous. This helps in breaking down the enormous task of recalling all projects I worked on in the past year and my takeaways from them. When I sat down to write my self-review, all I had to do was simply compile all of these docs in an easy, fun-to-read flexback document!

This year I’m really proud of the review I wrote and of course of the growth I have seen in myself. Thought of sharing this publicly on the off chance that someone might find it helpful in writing their own self-review.

Addressed to my manager, Abhishek Damodara (Director of Design, Graphy)

Review 2021 💪

The theme for the last year has been the exponential growth I have seen in myself across all areas. I constantly adapted to the needs of the company showing great flexibility which made me a valuable asset to the organization and the design team.

Since the last year was the foundation year of me as a designer there were learnings every day, so it was difficult to list them all down in an easy-to-read manner. Hence, staying true to the spirit of making the user’s (reader here) life easier I have broken down the achievements and learning into four buckets (i mean who does not like a little hierarchy)

#1 Ownership & Accountability

From requiring hand-holding at every step to shipping projects independently, there has been tremendous growth in the past year. I have successfully owned and shipped major projects. I drove half of all the projects we as a team have shipped. To list down a few:

1. Live streaming:
I demonstrated end-to-end ownership in every iteration, from designing the MVP of live streaming player to polishing and making it feature-rich. To name a few I worked on paid-handraise, polls, reactions, pinned messages, and pop-out chat from ideation to delivery. It was particularly interesting to solve for the complexity of designing for all platforms: web, m-web, android, and iOS.

2. Mobile apps:
i. Graphy Learning Community App: An app for the audience of Graphy creators to participate in live sessions, get access to course material, and interact with your fellow learners on the go. This was a project with the potential to have a significant impact on the numbers. Here again, I took complete ownership of the project from making components, defining information architecture to coordinating with developers. Personally, I consider the learner mobile as the project which brought out the best in me.

ii. Graphy Studio App: Graphy Studio was built to conduct online classes for an unlimited amount of time — for free. Initiated as a growth project for the core product. I set up and delivered the project in record time with high precision.

3. Design system:
Upon the merger of Graphy and Spayee the design team was tasked with the complete redesign of the Spayee product. For the redesign, it was imperative to set up a design system. For this, I actively collaborated with my colleague Utkarsh to kick start the process. Doing so required me to exponentially upskill myself. The output of this exercise was the component library all done in a period of 1 month.

Apart from the above 3, some other projects which I’m equally proud of were asset library, revamping of settings, redesigned Graphy learner dashboard.

#2 Team player

Being well aware of the company goals I always accommodated and did what was in the best interest of the company while mindfully taking away a lot of actionable learning. In the past year itself, I have successfully dealt with the volatility of 2 pivots and a merger, building from 0–1 twice!

Being the first designer in the team, as new designers joined in I helped them get onboarded onto the product, our processes, and the team culture.

#3 Continuous Learning

My biggest strength is asking and working on the feedback received. Over the course of the last year, there was barely a dull moment. I passionately delivered better on the project I’m working on from the previous project I shipped. Some of the areas of major learning while doing so have been:

1. Prototyping as a tool of communicating design and interaction
2. Scoping work for estimating project timeline
3. Auto-layout for modular component-based designing
4. Copywriting as a tool in my design toolkit
5. Breaking down complex problem statements and projects into consumable chunks
6. Effective communication for clarity and collaboration across the team

#4 Empathy

Across the board be it my manager, teammates, or the users. Understanding context and designing according to that is something I now understand way better.

Areas of self-development 📈

• Would like to step into a role where I’m managing and actively sharing my knowledge. Will help me discover if the path ahead for me is of an IC or a manager.
• Scoping and management of time is something I have focused on in the last month and is showing results. Would want to continue doing so.
• Confidently communicating and collaborating within and outside the team.
• Work-life balance is still a work in progress and I want to be in a position where I can calibrate this balance according to the needs but otherwise maintain equilibrium.
• Talking about and not just doing work, getting the ghettoed knowledge out in the world via blogs, write-ups, and social media.
• Overall ownership of the product by the design and product teams. Basically returning to being a product-driven company.
• Constantly working in a team where I’m challenged and humbled with talented folks around me.
• Seeing through pixel-perfect design not only in Figma but also live in development. For that to happen even if it requires spending a whole day or two reporting DESIGN BUGS and working closely with the frontend team it shall be allotted.
• Inculcating the brand language being developed into the product.
• Adding and rendering motion as a dimension in my personal design thinking.
• Develop a working relationship with frontend engineers. Something I feel has been a big-time miss due to remote work. Since that is not going to change we need to come up with creative ways for the engagement to take place.

You can find tons of articles on the internet about writing self-reviews. But while going through them and sitting to write your own remember it’s nothing more than a flex document. So flex away!! 🕺🦋

️Hope you found this helpful. If you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet @sanyamjain_

As a young designer, I too used to vaguely follow a process while designing, but upon working in a fast-paced product team that undefined process went for a toss. Working in a team environment with time constraints was new to me – this, unfortunately, meant an anxious me rushing to get things done.

Writing this blog is my urgent attempt to fix my design process, as writing often helps crystallize thoughts. Also, my hope is that someone with similar struggles might find value in reading this.

🥁

1. Write the problem statement

Debrief the brief for yourself. Like really ‘write’ it down. Make sure while writing you define the problem in the best way possible. This problem statement will be your one-stop reference to deal with the future sulking moments you might have.

2. Read, re-read and read it one more time

You think I just wrote the statement why read again huh? Think again, read again :P

3. Little internet research

Look up instances of similar problem statements. While doing so keep in mind every solution is context-specific. Try to understand the reasons behind the approach of those designs.

This exercise helps in identifying patterns and best UI practices in terms of components, spacing, copywriting, and hierarchy.

4. Start scribbling on paper

By now your head is bursting with ideas and you may have started conceptualizing the screens in your head. Your gut says let’s get done with this!

NO STOP, it is not pixel time. Dust off that notepad, pick your favorite pen, and start sketching. Sketch those ‘brilliant’ ideas and screen designs. Go wild, try every possibility.

Doing this is crucial to declutter your head and discover the best ideas.

“The only way to translate tasteful ideas in your head to tasteful designs is by doing a lot of work. Maybe you have 10000 bad ideas in your head but if you get all of those out you will have better ideas.”

5. Pick out the ‘good enough’ versions

Select the designs you feel have potential. The idea is to further refine them by iterating and gathering feedback.

6. Now make those pixels!!

We all know the drill. I mean who doesn’t like making colorful rectangles :P

7. Include a dark horse

This is something which helped me a lot! While designing make one (or two) conventional ‘will work’ designs but along with that have one dark horse.

Dark horse is where you go wild and make the best design without any inhibitions. The dark horse might not go-through but the exercise of making it part of the design process keeps things challenging, fun, and might even redefine what’s considered feasible.

And the dEsIgN process is done!! 🥳

Religiously following the above design process brought much-needed finesse to my designs. Also note, the process is not necessarily always linear it rather acts as a reference point to conclusively arrive at a design solution. If you are someone trying to establish your own process I hope you find some value having read this :)

Hi, this is Sanyam, if you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet to me @sanyamjain97

Identifying my design process was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Case study of end-to-end product design of an app enhancing the experience of exploring your city.

I’m writing this in the middle of a global pandemic. Tourism activity is zero, the start of any sort of tourist activity is far off. This situation is depressing for all but particularly for passionate travelers like myself.

I always felt major gaps in the touring experience for visitors, so I took it upon myself to fill in those gaps. Stuff such as the discovery and navigation of places can easily be solved by technological progress in Machine Learning & A.R. wayfinding. When combined with good product thinking, it can be a real boost to tourism activity.

By all means, restoration of city-based domestic tourism will be much earlier than global tourism. The product conceptualized here is particularly useful for that use-case.

Goals

The goal of this product is to enhance the tour experience by achieving the following goals:

1. democratizing regions within the city
2. accessibility for a disparate set of visitors
3. lifting community of city guides
4. aligning tour discovery to actual user intent

📲 Incase you want to play around here is the link to app prototype.

Research Insights & Problem Identification

I brainstormed about the above aspects to form some assumptions. Later, a survey done with 15 people validated my assumptions.

💡 Look for the bulb. I will be sharing insights from the survey through-out this case study.

(I) Discovering the Places.

• Available Options: Problems with them ⤵️
• Online Catalogues: Difficult to discover lesser-known places, scattered suggestions.
• Social Media/magazines: Lack of alignment with your intent

(II) Navigating the Place.

• Available Options: Problems with them ⤵️
• Google Maps: Fails in indoor settings, dependent on GPS, no curation
• Printed maps: Very limited availability
• Onsite wayfinding system: Limited in guidance, not in the preferred language
• Tour Guide: Non-standardised rates, available only at higher footfall sites, no reliability, language barrier, etc.

Broad ideations for the app

1. To make discovering places as easy as music discovery.
2. High level of curations along with easy navigation to provide a hassle-free experience.
3. Partnering with experts and travel enthusiasts for curating and discovering interesting places.
4. Carefully understanding and catering to user intent, for example suggesting a pet-friendly place to explore or a romantic stroll in the park.
5. Utilizing breakthrough in A.R. wayfinding.
6. Understanding and catering to a more conscious post COVID world.

📲 If you want to play around here is the final app prototype.

Let’s Build 🔨

For the sake of sanity in explaining this product I have divided it into 2 phases:

Phase 1 — Discovering
Phase 2— Experiencing

Phase 1— Discovering

Framework Development

For any discovery and recommendation to be made a basic framework to divide the city is to be formed.

Example Scenario — Within the City of Delhi, Old Delhi is a locality. It has lots of interesting spots that can be toured/walked in different ways.

This product offers curated packaged experiences called ‘walks’

Recommendations & Category Creation

People rarely go out to explore their own city our attempt is to change that by tying user intent with recommendations.

The number of walk experiences that can be offered is endless, in fact, the same spots in a locality can be curated in different ways to offer varying experiences.

To solve this problem I looked at how Spotify deals with music discovery and Airbnb with recommendations. Taking inspiration from their model categories were created to align with the user/visitor intent.

Example Scenario: The romantic category will hold walks in a picturesque and non-crowded locality. 💘

We address the numerous intent of users and create several categories according to it. In addition, machine learning can be used to dynamically update the walk suggestions.👇

Screens upon selecting a locality or walk 👇

Unique features in locality and walk sections —

1. Live Crowd: Useful in decision making.
2. Picture Spot: Label for popular picture spots on the walk. An important detail for the Instagram generation!

Lets’s have a look at the visual design of the app before starting Phase 2

Visual Design of the App

While designing I tried to stick to a singular design language to ensures predictability and consistency across the app.

💡 Material Design guidelines were looked at as a reference point for establishing design language.

• Montserrat Alternate was paired with Montserrat to give personality and character to the app. The stylish character goes well with the heritage & travel theme. It is mainly used for headings.
• Elevated cards with shadow and adequate padding are used to make the app look clean, more breathable, increase legibility, and help users consume more information in a focused manner.
• Red despite being the brand color is used sparingly in the UI, as red is also associated with danger and negative connotations.
• Following color psychology, green is used where navigation/wayfinding is involved. Green is symbolic of ‘go’ in many countries and gives a direction of moving forward, growth, and positivity.
• 9/10 times all rectangles are rounded to corner radius 4 for maintaining consistency.

Phase 2— Experiencing

(I) Defining Functionality

Looking at what all functions are required for an outstanding walk experience.

(II) Searching for Enabling Technology

✅ Refers to the chosen technology

For Navigation

• Using GPS enabled 2d maps like Google Maps.
• A.R. based wayfinding system. ✅

Reasons for not choosing GPS technology?
1. Limited it to outdoor areas with signal coverage.
2. A.R. can seamlessly integrate with the camera module.

For Information

• A.R. based image recognition.
• Geotagging spots ✅
• Scannable visual code stickers like App Clip in iOS 14 ✅

Reasons behind not choosing A.R. recognition?
To avoid too much reliance on A.R. as it can be battery draining.

(III) Designing the Interface

Now that we have defined core functionality & technology we can proceed towards designing the interface.

The interface for experiencing is divided into three sections —

Navigation — the magic happens

After several iterations, I was able to successfully and seamlessly integrate the two core functions, Camera & Navigation into a single screen.

Let’s take a look at the anatomy of this screen👇

Quick Navigate

• The most necessary amenities are accessible on top of the screen for quick access.
• Upon navigation, arrows change color from grey to green indicating a detour from the walk list.
• Upon reaching the location arrows restore to grey.

Walklist — view/modify walk

Although the attempt is to provide a curated experience to the user, at the same time it was important to give users a choice to modify the walk according to their needs. Hence, we have walklist!

As the name suggests, the walklist is inspired by the playlist and borrows its behavior from a music playlist.

Let’s take a look at the screens👇

Being a history geek, I love visiting monuments of all sorts and immersing myself in facts and trivia these places possess. I truly believe when the context is added to an otherwise bland stroll through an ‘old building’ it can impart people with valuable lessons.

That is exactly what I set out to do when meticulously crafting this product. Below is a look at my approach to solving this problem using information screens.

Accessing Information Screen

There are two ways to activate a spot pop-up👇

The reason for including scannable visual code was to make the information screens independent of walk experience. For example, if you are not in a walk and spot an interesting statue, in that case the code can be scanned to get information.

Information Screens

The information screens content depends upon the walk intent;
for example,

Scenario 1: If you are with your family or on a casual walk, information like picture suggestions would make more sense.

Scenario 2: A keen curious history buff might prefer a full in-depth read understanding the significance.

Multilingual: These screens will be in the preferred language of the user along with other aspects of the app.

Partnered Walk Screens

In the case of, walks curated by expert partners the screens can be personalized which can act as a way to provide value while incorporating partners interests, for example,

A walk curated by an acclaimed historian ‘Rana’ who has written a book on the place, can contain:

• Uniquely researched insights
• An ad/plug about her book
• Personalized audio guide

Similar partnered walks can be by travel bloggers, authors, or seasoned local tour guides.

The idea is to empower people passionate about a region to speak about it. Adding their unique insights and trivia to the visitor's experience.

End of Walk

Upon completion of the walk, the visitor/user is shown a dialogue asking for rating their walk experience.

It was imperative to have some sort of filtering mechanism for making the user's life easier while deciding which walk to choose. The input for that rating is acquired at the end of completed walk experiences.

Choosing the appropriate rating system:
Upon my research, I found there are several types of rating systems out there. This blog below proved to be useful which making the decision.

The Psychology of Rating Systems in UX

This product uses a uber sort of rating system where it first asks for a rating out of 5 stars for the walk experience and then a more specific ‘top spots on the walk’ selection. They cumulatively compute for the walk & location rating.

Although I don’t completely understand the math behind the working of the rating system, my attempt was to come up with the best possible solution on my end.

Possible product expansions

• Build creator tools for enabling a travel curator economy. Possible use cases can be travel bloggers and travel enthusiasts. Aligns perfectly with the trend of the passion economy.
• Add ticketing module to monuments, museums, etc
• Arrows for navigation can be showed on A.R. glasses. 🤯

Conclusion

I found this concept compelling to work upon and I really do hope something like this gets made. A quick shoutout to Gyan Lakhwani & Himanshu Seth for always nudging me in the right direction.

Hopefully, you found this article helpful and insightful, if so do share and hitttttt that clap icon. 👏

Hi, this is Sanyam, if you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet to me @sanyamjain97

• The future of Google Podcast
• Learnings from my failed attempt at Type Design

How can a breakthrough in A.R. wayfinding contribute to a world-class tourism experience? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why did I want to intern?

After having practiced design as a hobby for a long time involving various side projects and school projects. The natural next step for me was to experience the professional world.

As most work happens with great collaboration it was imperative to put me out there to understand what it feels like to work in teams with people of different skillsets and domains.

Finding an Internship

Since I was studying in an engineering college, I didn't have much of a network in design. The only option was to look through online portals where I found a startup called Marsplay, they were looking for a marketing design intern. Going through their expectations from the role, it felt the right place to apply.

I went ahead with sending my portfolio, which was followed by a design exercise and an eventual office interview. I joined their marketing team as a designer in January 2019, for a period of 8 weeks.

Marsplay is a Community-led commerce platform, envisioned as a platform that provides easy-to-shop fashion advice on ‘What to wear’ and ‘When to wear’.

The Story Behind Marsplay

My Role & Responsibility

1. Designing for External Triggers

A number of external triggers were employed for driving user engagement, i.e, daily/weekly/monthly/occasional challenges.

My role was to create a cohesive set of theme-based design assets for these challenges, keeping in mind —

• Consistency over various touchpoints like social media feed, story, and in-app banners.
• Consistency with the brand image of Marsplay.
• Consistency with the theme of the particular challenge,
  for example, ‘styling for summer’👇

2. Providing design assets for offline events

Marsplay was an early-stage startup pushing for hyper-growth, the team regularly organized offline promotional events for visibility. As part of this approach, Marsplay collaborated with Delhi University as the ‘official beauty sponsor’ for their cultural fests held annually.

I provided the following for actualizing the event:

• Digital assets for social media promotion.
• Print assets for a photo booth stall set up in the fest.

Key Takeaways

Being my first exposure to a professional environment there were massive learnings for me —

• Producing good work vs producing good work with deadlines are two different things.
• Participating in planning calendars and pipelining work for ease of execution.
• Understanding the sort of work that goes behind running an app, as even simple things like scheduling notifications is a complete job in itself.
• Being an early-stage startup at the time, we worked from a 4 room apartment this challenged my notion of an office.
• Collaborating with colleagues, reporting my work, attending stand-up meetings were all experiences that counted.

You can view the Behance presentation of my work here.

Hi, this is Sanyam, I think through problems to arrive at a solution, which is engaging and works. If you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet to me @sanyamjain97

The future of Google Podcast

Interning at an Early-Stage Startup was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reason for attempting type design?

I’m a self-taught designer with limited exposure to the realms of design typically taught in an art school hence it was imperative for me to try out everything before settling down on a niche.

The other motivating factor was that type design for some reason is held in high regard and can add much credibility to a young designer's portfolio.
Type design is the craft and process of designing typefaces.

Ok Now! How to start?

i. Researching

Reading and talking about everything type for the next few weeks, looking at youtube tutorials, skillshare classes with the single aim of educating myself with the processes to follow, essential software, and buzzwords. Listed below are some resources I found useful:

• Design your own fonts on Skillshare.
• How to make a custom font by The Futur.
• Thinking with Type by Ellen Lupton.

ii. Finding a core idea

The first thing to get started is to have a core concept around which the typeface will develop. Here the discovery of that idea itself is an interesting story. 😬

In 2019, I was going through old entrance exam papers of design colleges in India, there I found this question —

“ There are three friends, two of those want to surprise the third on her birthday so they order a cake. By mistake, the bakery delivers cookies instead of cake, as they discover this the third friend enters. What will they do now? ”

My solution to this problem was to cut the cookies strategically in a way that letterforms are created, which are then used to make the word “Happy BDay”. I saw potential in this concept and decided to develop it further.

The Process

Step 1: Drawing all the letters

Simply drew all letters on paper sticking to the core concept of cookie bite.

• The cookie remains fixed in size.
• The bite-size changes using which different letterforms are achieved.

Step 2: Moving to illustrator

I quickly clicked a picture moved that rough draft to illustrator (which I later realized wasn't a good move, iterate people!!). Thereafter, I took these rough forms to make vectors using the easiest way — the pathfinder tool. I had no idea about how Glyph software works so for the start illustrator was the tool.

Step 3: Identifying problem letters and reaching out

After executing a few letters it did not feel coherent and for long I was just stuck in a state of limbo. To troubleshoot that problem I reached out to senior designers.

Step 4: Stepping back and building sensitivity

After struggling for a month and having exhausted myself with online tutorials I reached out to a professional type designer Namrata Goyal. She looked at my work and before anything else suggested me to do some observational type exercises to build sensitivity and understanding of how type actually works.

“Type design is about function. Drawing pretty shapes isn’t enough.” — James Todd

Some of the exercises were:

• Choosing standard fonts and making notes regarding which shapes are similar in; form, size, width & round shapes.
• Tweaking/relaxing my core concept and exploring how letterforms would shape; let's say if multiple cookies came together or multiple bites on a single cookie.

Step 5: Iterating until ultimately shelving the project :(

Putting the exercises into use I made a few iterations but even after that, it still felt far from a coherent workable typeface. Eventually, I decided to shelve the project deeming it unfeasible. The major problem in continuing was my limiting skillset and unwillingness to go through with the steep learning curve involved in creating a typeface.

What I achieved👇

Moving on

Although, I failed in my endeavor to create my first typeface the attempt wasn’t futile by any means. In fact, I would regard it as a success 🥳 as the primary objective for me was to “try out everything before settling down on a niche” and now I can assuredly say that type design is something not for me, so let's leave it to design grads.🤓

“You’ll figure out what you want by trying different things, by simple problem solving, by the process of elimination — not a formula.” — Sah Kilic

So, what’s next? the answer to that was product design. For that, I worked on — Rethinking the Podcast listening experience and what that would look like. That project turned out pretty well check it out.👇

The future of Google Podcast

Hi, this is Sanyam, I think through problems to arrive at a solution, which is engaging and works. If you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet to me @sanyamjain97

Learnings from my failed attempt at Type Design was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Redesigning for a more fine-tuned and immersive listening.

As an avid listener of podcasts, I have always felt that podcast listening experience lacks imagination as they are either tied within the music app or ‘dedicated’ podcast apps which are not very different.

In reality, listening to songs vs podcasts are two entirely different user experiences. Here, I attempt to provide a more fine-tuned and immersive podcast listening experience.

The history of podcasts dates back to 1999 with the development of the Real Simple Syndication Feed (RSS) and it’s been around since then in some form or another. In 2005, with the entry of Apple into the market increased the accessibility of podcasts all over the world. Ever since the listener numbers have witnessed a steady rise with 2019 being considered the breakout year for podcasting.

The name podcasts are the combination of ‘iPod’ and ‘broadcast.’

By podcasting, you can close off the distance between you and your target market. It ensures you get a closer relationship with your audience by providing informative, engaging, and frequently updated content. This project is an inspection of the roadblocks and thereby proposing a design solution for making podcast realize their potential as the future of radio.

Identifying the problem

Historically we had “audio players” that played all audio formats be it clips, songs, or podcasts. For songs, over time the audio player has metamorphosed into a “music player” in apps like Apple Music, Spotify with features like synced lyrics, song insights, better queuing whereas the podcast ecosystem still relies on the “audio player” for playback.

My attempt is to change that and envision an explicit “Podcast Player”.

Let’s inspect the major problems with the existing system.

1. Listening Experience —
   The length of a podcast episode can range anywhere from 5 min to several hours and the chances of losing attention are very high so when you get back to resuming an episode some sort of cues to remind the previous section would be helpful.
2. Monetization — 
   Although the podcast market is rapidly growing it still suffers from the problem of being under-monetized, the rates for an advertisement plug in a podcast episode are much lower than other digital mediums.

Goal

To envision an explicit “Podcast Playing Experience”.

Scope & Constraint

The podcast market is witnessing serious growth. A product that can provide a tailored experience to the rookie, as well as veteran listeners, shall act as a catalyst to that growth.

Since many podcasters are independent creators a product that can help raise their revenues will effectively be a promoter of the format itself.

2019 has been considered a breakout year for podcasting, according to Edison Research’s Infinite Dial report.

With a big problem comes big constraints, here the biggest constraint was the fact that people mostly listen to a podcast while engaged in some other activity and barely interact with the device or the app where it is being played. This meant we had to approach the problem where we don’t wholly require their attention.

Solving Problem 1 — Improving the listening experience

1. Introducing contextual cards

“Adding context to content”, often being unaware of certain things being spoken you end up googling it, which makes you leave the app distracting from what’s being currently spoken. This is where visual cue cards come in.

2. Defining the cards

Taking this concept following categories of cards were created.

• Information: Unfamiliar terms & visuals can be described here with an option to add a weblink.
• Quote: Highlights an important piece of dialogue or advice given by the speaker/guest.
• Connect: Quickly connect with the guests.

Note: I have chosen the design system of Google Podcast for present my idea.

3. Re-designing the Interface

Existing podcast playing screens barely differentiate themselves from music playing screens. My approach was to integrate the cards within that space without compromising on the overall functionality.

(I) Finding Space for the Cards
Typically cover art occupies the majority of the screens which makes sense for songs as they add personality+customisation to the content. This logic doesn’t apply to the podcast, because often the user is just listening to yet another episode of a show he is already invested in.

(II) Placing essential components
Here we divide the components into two groups with

1. Pause, forward/rewind & the progress bar placed on-screen for direct access
2. whereas additional options of the playback speed, sleep, info, playlist & share the episode neatly open upon clicking the meatballs menu.

Thought behind the change:
The additional options don’t take up any new space on the screen as to not disturb the ‘immersive experience’, but once an option from the meatball menu tapped then it expands as now the user has committed to that choice and would not mind the visual disturbance caused. This small maneuver gives the user time to think.

4. Defining Interactions

(I) Progress bar into a slider

The pre-defined role of the progress bar included —
Providing a visual sense of the time elapsed and skipping through an episode by dragging the knob.

What do we change?

• We attach pins in the shape of smaller knobs along the length of an episode.
• These pins are linked to individual cards and upon overlap with the now playing knob get activated and display the linked card on the screen.
• The two possible behaviors are:
  (i) knobs automatically get activated as the track progresses
  (ii) the user can intentionally drag to that location

(II) Swipeable Cards

Simply swipe through the cards without affecting the playback, this allows a preview of the episode with additional options to

• view all cards in a stacked manner.
• jump to a section of an episode by tapping on the timestamp on the top left corner of the card.
• bookmark the card with the timestamp.
• share the card with social media.
• undo (gets activated when a sudden movement of cards is detected).

5. Feedback, research, and iteration

Feedback

After going through the above process, it was time to seek feedback and test out the concept. For this purpose, I approached my mentor Gyan Lakhwani, and he highlighted some important pain points —

• Who will create these cards?
• How will you convince podcast hosts to package things in your format?
• What can you do about the monetization of older podcast episodes?

Utilizing the Feedback

I realized the missing aspect while developing the idea was in-depth research around podcasts in terms of market trends, interests of creators/platform as well as demographics of listeners. What followed was —

Step 1: Reaching out to people and understanding their concerns.

Speaking to casual and avid listeners of podcasts highlighted some useful things like

• The mode of listening i.e, active/passive listening greatly depends on the podcast they are listening to.
• In some cases, listening is complemented by active note-taking.
• It validated the hypothesis I made about the problem with podcasts.

Step 2: Conducting in-depth online research.

This was most useful and gave us our second major problem to solve, the issue of under monetization of this medium.

I talk about it in depth later in this post.

Step 3: Competitive Research

• I discovered apps like Entale & Adori, they have been trying ‘enhanced podcast’ for a while.
• Studying their approach gave me ideas about making a better solution.

Solving Problem 2— Monetisation

1. Increasing Discoverability

• The concept of cards is customized to add meaning and context for the podcast format, thereby increasing the chances of people sharing them.
• Second, most podcasters with limited technical skills find creating digital assets for promotion a chore, so these cards which can be simply created using templates can later come in use as digital assets for promotion.

2. Ad–Cards

Advertisement is the primary source of revenue for digital content.

In addition to the 3 cards, Information, Quote & Connect which are presently part of the concept a fourth card for placing advertisements is introduced, it’s advantages being;

• Adding context and a direct link to reach the advertiser, to backup the audio placement in the show.
• Older content which is unmonetized can also be monetized.
• It can act as an incentive to buy a premium subscription, for an ad-free experience.

Finally, I will end this by answering two essential questions.

Q. What’s in it for listeners?

— Flexibility to listen & added context to understand better.

Q. What’s in it for podcasters?

— Discoverability & growth in revenue for eventual self-sufficiency.

Hi, this is Sanyam, I think through problems to arrive at a solution, which is engaging and works. If you’d like to get in touch, send me an email at sanyamjain18@gmail.com or tweet to me @sanyamjain97

The future of Google Podcast was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.