PRAY - CONNECTING YOU & TEMPLES

ROLE
Product Designer
TEAM SIZE
2 Designers
RESPONSIBILITIES
Product Design & UX/UI Design

OVERVIEW

PRAY - The mobile application that allows users to find temples in India and engage with them. Users can make donations, join volunteer groups and be informed of their favorite temple's  various activities. This product gives users a chance to appreciate their local temple for the work they do. The web application allows the customer to feed and manage temple data on the mobile application and provides analytics of temple interaction. 

 

DISCLAIMER

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this project. I have given a sudo title to the project, hidden few elements, and have not explained workflows in detail. The project displays my thinking, abilities and skillset without tampering with the NDA.

 

PROBLEM

The stake holders came to us with a problem that bothered them a lot. Something close to their hearts and something that they thought can be tackled by a well thought through digital product. We heard them out and boy was it relatable!

"The millennials loosing touch with their religion"

"No awareness of Indian culture"

"Kids these days don’t understand or know a lot about our religion"

These were the problems.  Be it places of worship, religious stories, science behind many blindly followed mythologies, ways and means of a culture, traditional rituals and so on, millennials were misinformed or unaware of them all. A very ambitious father and son duo recognized this void and decided to give back by attempting to bridge this gap using a digital product. Since  millennials are lost on their phones all day what better than a mobile application. This is were they thought of us.

MY APPROACH

01

Discovery

Product Discovery Workshop
Persona

Mind Map

02

Design

User Flow Diagrams

Wireframes

High Fidelity Mockups

Interactive Prototype

03

Validation

User Testing

Iterative Design Changes

 

DISCOVERY

To start with we conducted a two day PDW (Product Discover Workshop) with the stakeholders. Prior to the PDW, we gave them a list of questions which we wanted them to think about and come prepared for on the day of the PDW. The questions were not limited to the following but  they guided the conversations in a direction that uncovered the project more.

 

The questions included :

  • Describe the platform in a single sentence.
    Pray is for < fill target audience > to < perform core functionality > with ease. 

  • What is the vision?

  • Why should new users use Pray?

  • What is Pray’s unique selling point?

  • What are the obstacles the users will face that might stop them from using the platform? 

  • What are the hurdles that you are expecting?

  • List 5 abilities of the app in order of priority (descending).

  • If we are to design a MVP, what are the features that will be prioritized? 

  • Explain the offline workflow/activities. 

  • How are you going to get the temples to onboard?

  • How are you going to monetize the platform?

PDW DAY 1

Goal for Day 1 : 

  • Complete understanding of the domain.

  • Discovering the long term vision and strategy for the mobile app we are building. 


They came prepared with answers for our questions, all went well and we had a clear picture of the direction the stakeholders wanted to steer the product towards and their idea for the future. The solution to the problem was now taking shape as a product with abilities and features. 

PDW DAY 2

Goal for Day 2:

Time to get creative! Having a solid understanding of the domain and, an overview of our target users , it was time to take the process one step forward and dive into the features and its architecture. 

 

Based on our understanding from Day 1, we did little homework and mapped the user flow for the entire web app and mobile app. This discussion will lead to progressive iterative changes. We indulged the stakeholders in an activity of card sorting which made them feel included and gave them a sense of ownership on the process.

PDW TAKEAWAYS

  • Requirements for the MVP

  • Clear understanding of online and offline workflows.

  • Understanding of the business strategy, the core goals and what the client was trying to accomplish.

  • Clear understanding of the target audience and a distinct personas to get a good grasp at who we were designing for: Their needs, behaviors and goals.

  • The mobile application has to be completely consumer facing. 

  • The web application has two user roles. One is the stakeholder who will be called the Super Admin. The other role is of client who will be representing the temple and will be called the Temple Admin. 

  • A detail mind map of the mobile and web application. To comply with my non-disclosure agreement, I can not disclose the mind map of the entire application. Below is a part of the mind map that gives you an idea of what is usually looks and feels like. 

A part of the mind map of the mobile application

 

USER FLOW DIAGRAMS

With the mind map ready, we went further into the nitty gritty of things and made user flow diagrams for the mobile and web application. For logistical reasons I can’t possibly include all the UFDs we worked on and its iterations, but below is one example of what these usually look and feel like:

A part of the user flow diagram of the mobile application

EXPLORE - PROPOSED FEATURE

Keeping the persona's goals in mind it was important for us to think of hook to bring the users back to the mobile application. Aim was to create a space that would intrigue the target audience and make them want to open the app often. After a lot of brainstorming we decided to propose the idea of having a space that would generate content on daily basis that will grab the users attention by giving them exactly what they want towards their goals. The stakeholders loved the idea. So we went ahead and add this new feature.

External Trigger - Push Notifications

Internal Trigger - Be informed of the science behind religious rituals and myths in a modern, more socially acceptable way. 

 

Action - clicking on notifications (push) - Mimicking instagram/FB etc.

Reward - Quenches the thirst of knowing the whys and whats of religious science, interesting conversation starters, connecting generations

 

Investment - Creating a space for more such information. Allowing the user to expect more the next day (depending on decided schedule).  

 

WIREFRAMES 

Once we were comfortable with what we had, we decided to move to wireframes and start thinking about how the interface would actually work. We started slowly, focusing on the core interactions and gradually expanded to cover everything that was needed. This was an extensive wireframing exercise. A lot of smaller, essential details, needed to be taken care of. 

We tested the wireframes with potential users, documented the feedback and made the necessary changes. A lot of iterative fixes were done to the design that would enhance the user experience of the final application.  

VISUAL DESIGN

The wireframes provided a really solid foundation of the core UI elements. Once we were happy with where we were, it was time to move on to higher-fidelity representations and incorporate the brand and visual elements. I am not going to talk about the brand at this point. Below you can see the visual design screens of the wireframes above. These are not the final mockups because they were and are being updated after the user testing. To comply with my NDA I have presented only the pre-approved screens.

MOBILE - VISUAL DESIGN

EXPLORE - VISUAL DESIGN

Below are the visual screens for the explore section which we proposed after the product discovery workshop. The stakeholders loved this part of the application and were all geared and motivated to start generating content. After an intense meeting with the stakeholders and content generators, we had decided on 3 kind of contents. 

1. Daily verse with its meaning

2. Daily message or tit-bit explaining the science behind religion

3. Articles linking back to the temples in the application. 

WEB - VISUAL DESIGN

VALIDATION

I conducted user tests with the recruited candidates and got some interesting feedback which I then solved for in the mockups and prototype. For the user testing, I gave the candidates mock scenarios and presented them with the interactive prototype. I requested them to talk aloud and assured them that it is not a test for them but rather the product. Due to my NDA I am unable to share the test findings and how I handled them.

The stakeholders were really happy, engineers confident it can be built within the timeline, and the testing sessions we ran were overwhelmingly positive. All in all, I can definitely say this was one of the most challenging projects I had the chance to work on during this year.

KEY TAKEAWAYS

  • In a complex product as 'PRAY' having a clear vision helps in the production of an MVP. The user behavior with the MVP should be analyzed and only then we should move to phase 2.

  • The value of intermittent user testing is incomparable.  

  • Including the dev team in the PDW helped us navigate many feasibility issues which could have derailed our timeline. 

WHAT WOULD I HAVE DONE DIFFERENTLY?

  • After the product discovery workshop, I would have taken some time to conduct more user interviews with the end-users. We might have limited our sample size because of the timeline. I think many services company face the issue. 

  • Tried harder to convince the stakeholders about the color scheme. ​

  • This is a classic example of a feature first product. As a more mature product designer now I believe this was a wrong approach.