Revamping Apna app’s job search flow in 48 Hours — A case study

Case study about the reasons and the process behind the decision to change the way users can apply and track their job in the Apna app.

📍The problem:

You were struggling to find a job.

Desperate for any leads, you turned to job-searching apps.

One day, you came across the Apna app.🥳

Excited at the prospect of finding your dream job, you eagerly opened the app and started searching and applying.🧐

But as time passed, you found it difficult to quickly search and find the jobs you applied for, and your anxiety began to rise.🥵

Eventually, you closed the app in frustration.😓🤧

….

And this is what we set out to solve🤩.

Okay…but how did we get here? Let’s dive into that.

Overview👋

I recently participated in a hackathon organized by UXM community under the mentorship of Anudeep Ayyagari (UX Anudeep) that had over 120 participants. The goal of the hackathon was to come up with improvements for an existing product. Teams were formed and given a problem to work on. Each team had to choose a problem, research it, come up with solutions, create prototypes, test them, and present our findings in just 48 hours.

We were a team of six: The Misfits

1. Devv Kansana
2. Rohita Patel
3. Rajani Devi
4. Monica Chilagan
5. Preeti Wadhera
6. Jeganathan C (Me 🙋‍♂️)

We were given a list of different apps to choose from for the hackathon, and we decided to work on Apna

We chose Apna because:

• It is different from other hiring platforms in that it allows job seekers to contact employers directly. So this concept seems to be interesting to us
• Also one of our team members had experience in hiring as an HR, so we thought it would be helpful and will give us an advantage in understanding the problem.
• We also thought that working on Apna, which targets blue-collar and grey-collar workers, would be interesting and relevant due to the increasing popularity of grey-collar workers among big companies.

💎My Contributions in this teamwork:

Though I was primarily responsible for UI design and secondary research throughout the hackathon, I also helped out with any other tasks that the team needed assistance with.

Here is a list of the tasks I did and was a part of:👇

• Assisted in analyzing screen flows.
• Identified problems through heuristics and intuition-based evaluations of each screen.
• Formulated solutions based on assumptions.
• Contributed to desk research and brought in relevant insights to support our hypotheses.
• Conducted competitor analysis as part of our research to support our hypotheses.
• Mapped the validation or invalidation of our hypotheses with respect to insights from secondary research.
• Helped the team map insights from primary and secondary research to our hypotheses.
• Created HMW (How Might We) statements.
• Designed and prototyped the final UI screens.
• Conducted 1 out of 4 usability testing interviews.”

Disclaimer:🤫

This case study has two sections:

• Outline of the case study: This section will give you a brief overview of the solution we came up with.
• Detailed case study: In this section, you can find more information about how we made specific decisions, how we arrived at our solution, and how we managed our time effectively.

Move directly to Outline of the case study | Detailed case study

📜Index

🔖Outline of the case study:

1.1 Breakdown of the problem and flow

1.2 Comparing existing vs redesigned screens

1.3 What’s in Redesigned screens

🔖Detailed case study:

Level 1 — Problems

1.1 Understanding the users and business

1.2 Breakdown of the flows of the app

1.3 Finding Problems in the existing flow

1.4 Hypothesizing & assuming probable solutions

Level 2 — Validations

2.1 Desk research

2.2 Competitor Research

2.3 Primary research

Level 3 — Solutions

3.1 Wireframing

3.2 Making the UI screens for Usability testing

3.3 Usability testing with the redesigned UI

3.4 Final UI solution

3.5 Takeaways

📌Outline of the case study:

1.1 Breakdown of the problem and flow.

💎The problem statement:

Evaluate the job search and application flow of the Apna app and redesign the experience with the goal of reducing the bounce rate and increasing daily active users.

💎The flow we evaluated:

Home → search job → filter → applying → Track applied job status

💎What needs to be improved?:

From a business POV:

• Figure out why people are leaving the app and find ways to reduce the bounce rate.
• Increase the number of daily active users on the app.

From a user’s POV:

• Make it easier for users to apply for and track the jobs they have applied for.

Before we proceed, below is how the order tracking experience was like, before the revamp:

Existing Job search flow of Apna

💎This is after we revamped:

Revamped Job search flow of Apna

📍Comparing existing vs redesigned screens

📍What’s in Redesigned screens:

Curious about how we came up with this solution? It’s time to take a deep dive into the process:

📌Detailed case study:

We were provided with strict timeline for this hackathon:👇

Timeline for Hackathon

We had a tight deadline of 48 hours to complete all of these tasks, so it was a race against time for us. We have so much to do, right? That’s why we categorized these works into three level games:

🌟Level 1🌟 — The Problems

🌟Level 2🌟 — The Validations

🌟Level 3🌟 — The Solutions

So it was like a game between “The misfits vs The panic monster (TIME)”

We tackled all these using the Design Thinking process as our guide.

“Design thinking is a non-linear, iterative process that teams use to understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test.”

Basically, it means: “I am not the user; I don’t know what really works for the user; Let me experiment and find out.”

With that in mind, we kicked off Level 1 of our game plan

🌟LEVEL 1🌟- The problems

1.1 Understanding the users and business:

To tackle all of these levels, we realized the importance of understanding the basics of the business and the users. It’s kind of like how you can win a game without understanding the controls.

So in this stage, our team focused on fully understanding the problem statement, including the product, research problem, business, and user needs. We gathered the following insights:

💎Understanding the business

1. Apna is a platform that connects job seekers with employers and HRs.
2. It is a professional networking platform that helps blue and grey-collar workers find communities and jobs.
3. The rise of digitalization has led to an increase in grey-collar workers, and Apna has the potential to attract these users.
4. The target demographic is 18–30 year old blue and grey workers seeking job opportunities or to hire someone.

💎Understanding the users

1. The need for the problem statement

The goal is to improve the user experience by creating customized packages. Users may be unable to choose or become confused and frustrated, leading them to leave the platform. The problem also includes finding ways to increase active users by creating good engagement to keep them coming back.

2. Understanding the targeted users

The target demographic is blue and grey-collar workers aged 18–30. The transition to tech jobs for grey-collar workers is high due to digitalization, and these workers may face difficulties finding jobs on new platforms.

3. Understanding the impact on the business

Solving this problem would have a positive impact on the company by reducing the bounce rate through easy application flow and increasing the number of active users on the app through good engagement with users.”

1.2 Breakdown of the flows of the app

In order to understand and visualize the flow, We took screenshots of the app’s journey and identified the main steps (or “macro flow”) of the process to better understand and visualize how the app works. The macro flow consists of four steps:

1. Search ( Home search and Search page),
2. Listing page,
3. Job details page, and
4. Job tracking page.

This breakdown allowed us to focus on each screen flow in more detail.

Existing Job search flow

Existing Job apply flow

Existing tracking application flow

1.3 Finding Problems in the existing flow

Okay, I know what you’re thinking. You’re like, “Wait a minute, you said you’re not the user and you don’t know what really works for the user, but now you’re trying to find out the problem on your own instead of just talking to them?” Well, here’s the reason: before we speak with the user, it is useful to have some assumptions about the possible problems they may be experiencing.

And no, we’re not just pulling problems out of thin air. We’re using the detective’s kit called a “Heuristics evaluation” to help us identify potential problems, along with our own intuition to come up with a list of potential problems.

We find certain issues more intriguing. For example, clumsiness on the home page, and the lack of necessary information on the job details page etc., Below is a list of problems we identified on each screen based on heuristics and intuition:

1.4 Hypothesizing & assuming probable solutions

We have been examining the existing flow and have found some problems. We are not sure if these are real problems yet since we haven’t validated those. so we are coming up with potential solutions as hypotheses.

This will help us fix repeating issues, understand the big picture better, and know which parts of the process need more research and brainstorming.

So we discussed all the problems we noticed during the evaluation of the process and thought of possible solutions & listed out our hypotheses as follows

👉Home page:

1. Our hypothesis is to redesign the search option on the home page because our assumption is that for users the homepage can be a bit overwhelming because there are no divisions or sections, therefore users may have problems processing the information which can frustrate users

2. Our hypothesis is that the homepage can be utilized by giving CTA for multiple sections like searching jobs based on skill/Job role or Top Companies, etc. so that people can reach their primary goals (applying for the job) because our assumption is that big text become obtrusive. because of Inconsistent Font sizes, it’s hard to focus when too many text types are fighting for the user’s attention.

3. Our hypothesis is to provide clear copywriting on the banner so the users will be able to take action or notice the banner because our assumption is that the banner does not signify quickly that it has a tutorial on how to apply for jobs for grey and blue-collar employees.

4. Our hypothesis is that my job section should be clearly visible to the users because our assumption is that the after applying to a job users need clear action to track that job. If that is not found clearly, users might get frustrated and lost.

👉Search page

1. Our hypothesis is that recent search history/keywords should appear in the search bar because our assumption is that Users might feel the need to re-select their previous searches because we should make the user recognize his previous search instead of recalling it from his memory.

2. Our hypothesis is that providing no results when a user types in a wrong spelling can discourage users instead providing users with relevant searches can stop them from dropping off.

3. Our hypothesis is that to keep users informed the location that they are looking for should be kept below the search bar because our assumption is that users may find it difficult to search without any cue like here it doesn’t show previously searched job history or any suggestion based on the job details filled.

4. Our hypothesis is that adding cues like “search by skill or job type” will help users to get customized job results to apply based on their needs because our assumption is that users may find it difficult to search without any cue like here it doesn’t show previously searched job history or any suggestion based on the job details filled when login/Sign up

5. Our hypothesis is to Show upfront content like “ Search by Jobs “ or “Search by Skills”. because my assumption is that in search, when users looking for specific roles (e.g. skill ), all the categories is showing up increasing the cognitive load.

👉Listing page

1. Our hypothesis is that there should be an option to save the jobs because our assumption is user wishes to visit the jobs again to apply later.

2. Our hypothesis is to give a location search near to search bar because my assumption is that users need to go all the way to the home page to change the location and after going to the home page also user will be able to tag only a single city

3. Our hypothesis is that we should add a location icon near the location because my assumption is the location with the dropdown at the top can create confusion for users as no title is given and there is no division. It is merging with other information

4. Our hypothesis is to provide a location bar in the listing page because my assumption is that the users would find it annoying if they were browsing for multiple cities.

5. Our hypothesis is to group the content inside the job card based on their proximity because our assumption is that the users would find it difficult to analyze the multiple info like location and other job requirements which are different but grouped together.

6. Our hypothesis is that provide a popup on top of the icon e.g. No test is required icon to give a description of the icon because our assumption is that on the listing page, users may not be able to identify icons which are new to them. They have to go back in the filter, and read the icon description to understand it

7. Our hypothesis is that “Sort by distance to far” does not have a clear specification about distance on the listing page because our assumption is that the user will not able to identify how far one location is from his place. Recognition rather than recall

👉Filter page

1. Our hypothesis is that giving more options will make users more customization options so that they can easily find their required jobs because our assumption is that users have no clarity about how to apply the filters. Options given under the filter section are not reliable for the user

2. Our hypothesis is that Salary options mentioned in the filter need to be tagged with a currency symbol because our assumption is that the user might not understand what exactly the filter is about.

👉Job details page

1. Our hypothesis is to provide a link which can directly take you to the company profile because our assumption is that on the Job details page, Users want to know more about the company and its culture, to gain trust.

2. Our hypothesis is that if we replace the location icon used in the existing screen with a more relevant icon, it would make more sense to the user because our assumption is that users can easily recognize the icon used in other apps instead of learning a new one.

3. Our hypothesis is that the different sections of the job details page lack consistency in terms of alignment which can cause users to get frustrated and eventually drop off and we are yet to ideate solutions for this.

👉Tracking

1. Our hypothesis is that Make the “My Job” area more prominent because my assumption is that the button is not clearly visible enough to the users, which they use most of the time to see their pre-applied jobs.

2. Our hypothesis is to provide a “My Jobs” section on the homepage because our assumption is that in the current app the section is not clearly visible. It may make the users miss some important feedback from the applied jobs

3. Our hypothesis is that there should be an easier way to track applications because our assumption is that on the current screen, application status are denoted in text. If two application with two different status shows the text, Users have to read the text on both of them to distinguish them. This may increase the cognitive load and frustrate users.

Now that Level 1 is finished on a positive note, it’s time to move on to Level 2 of the game, which is “Validating our hypotheses”

🌟LEVEL 2🌟 — Validating

Till now, we have created hypotheses about potential problems and solutions that users may encounter based on our assumptions. However, we need to confirm that these are accurate. To do this, we went to do research with real users

BUT! We now had a bigger problem to deal with our enemy called: Time (AKA “The Panic Monster😱”)

The problem is we had only limited time. With that time it is possible to conduct only 4 or 5 user interviews. We felt it is highly not possible to validate all of our hypotheses with that. Add to that each user is a different kind of person. So it is not possible to validate every hypothesis.

So to sort out this, We planned to do secondary research which includes competitor analysis and desk research. This secondary research insights were already tested and proven by other businesses. So validating our ideas with those insights will make us to take less risk in our app.

So now we have to do three tasks👇

1. User interviews (Primary research)
2. Competitor analysis (Secondary research)
3. Desk research (Secondary research)

So our plan is sorted, right? NOOOOO😤!

We had an additional issue to deal with. Until now, we had been working as a group on all of our tasks. However, we now have three different tasks that need to be completed within a limited time frame. The panic monster is ticking behind us. We realized that it would not be possible to complete this level if we all worked on a single task.

So, we created a new plan called “Diverge and Converge”. The plan is simple: two-person teams. Each team will work independently on their assigned task and then come together at the end of the level to share and discuss the findings to validate our hypothesis.

Diverge & Converge Plan

So the plan is in place now. The next steps are to continue executing the plan and to make sure that we are on track to reach our target.

2.1 Desk research

Here are the insights we gained from conducting desk research,

Insights no: 1👇

When users select from search suggestions rather than typing in their own complete query, they benefit because they use less mental effort to search. Source

Inference we took: Users often have trouble remembering previous searches, so recent search functionality can help by reducing the amount of information they need to remember. This can improve the user experience and make it easier for them to find what they are looking for.

Hypothesis validated: Our hypothesis is that recent search history/keywords should appear in the search bar because our assumption is that Users might feel the need to re-select their previous searches because we should make the user recognize his previous search instead of recalling from his memory.

Insights no: 2👇

2. Insights gathered: Customization let users make their own selection about what they want to see, or set preferences for how information is organized or displayed. It can enhance user experience because it allows users to control their interaction. Source

The inference we took: Offering users the ability to save jobs can help them to customize their experience, and it can also increase engagement and the number of daily active users for a business.

Hypothesis validated: Our hypothesis is that there should be an option to save the jobs because our assumption is user wishes to visit the jobs again to apply later.

Insights no: 3👇

3. Insights gathered:The listing page is ground zero for analyzing the many available options and it needs to support efficient scanning and decision-making. Source

Hypothesis validated: Our hypothesis is to group the content inside the job card based on their proximity because our assumption is that the users would find it difficult to analyze the multiple info like location and other job requirements which are different but grouped together.

2.2 Competitor Research (Comparing with similar apps for insights):

As the desk research was going on one side, I and Rajani planned to do the competitor research on another side to manage our time and validate our hypothesis.

Why we did Competitor Research: If something is good in our competitor app and it’s doing good means they may previously test with users and validated that idea. So analyzing them and getting ideas from them will help us in taking less risk in our app.

In competitor analysis we mainly focused on two things:

1. How did they address the specific problems that were similar in our app?

2. Validating the hypothesis that we created.

So We picked three apps (Naukri, Hirect, and Linkedin) to analyze. We separated these three apps into two categories

1. Direct competitors — Hirect and Naukri
2. In-Direct competitor — LinkedIn

💎Direct competitors: Hirect & Naukri :

Why: Both of the other apps have the same business model as Apna, and they both have similar job search and job application flow. We wanted to analyze their job search and application flows, as well as their process for tracking applied jobs, in order to identify any potential improvements or insights that we could apply to our own app.

Analysis of the job search flow in the Hirect app

Analysis of the job search flow in the Naukri app

💎Indirect competitor: LinkedIn

While LinkedIn has a job search flow, its core business is connecting users with companies, recruiters, and other professionals. Therefore, we view them as an indirect competitor. We used their app to analyze how they solved the problem of tracking applied applications, etc. Even though their focus is different from ours, their approach to these specific problems may provide us with valuable insights.

Analysis of the job search flow in the LinkedIn app

Here is the list of Hypothesis which got validated from Secondary Research:

Hypothesis validated from Secondary Research

2.3 Primary research (AKA. User interview):

Team C went on to conduct the primary research. The whole plan of doing these user interviews was to find out that the problems and hypothesis we assumed are correct and also to find if there is any new problem which we didn’t find.

Before the team went for the user interview, We all sat down and planned the probing questions and things to avoid biases while doing the interview.

The PLAN:

Target group age: 18 to 40 years old. Because they are the prime users of our app.

Target users: Users who already know and use Apna / users who don’t know about apna but have job searching experience in other apps.

Interview mode: In-person interviews. Instead of doing a video call, we planned in person interview to conduct the usability testing of the existing app. We felt that in-person interviews would allow us to more effectively explain the tasks that users needed to complete and to observe their reactions to different elements of the app.

Questions guide:

Pointers which act as guides for our primary research

We did the testing in the following manner:

We asked the user to download the Apna app and complete the following tasks: land on the homepage, explore the homepage, search for a job without using filters, apply for a job, and find their previously applied jobs. As the user completed these tasks, we made notes about their behaviour at different points of interaction:

Insights from the user interviews

Due to time constraints, we were only able to interview 5 users. We took notes on the challenges that they faced and used this information to gain insights. Here are some of the insights we gained from the interviews.

1. Some users thought the banner feature was an advertisement and skipped it until they were asked about it.

2. Aravind found it overwhelming to have so much information on the homepage. It was difficult for him to focus.

3. When using the search function again, Kiran and Akshay were concerned about not being able to see their previous searches. They felt that they had to type the same search again.

4. Aravind looked for a save or wishlist option on the listing page to save the job for later use.

5. Akshay had trouble changing the city on the listing page. He felt that it was wasting his time because he had to go back to the homepage and search again to see the results.

6. Hemant thought that he could apply for a job from the listing page because the job card provided enough information about the job.

7. Kiran felt that using the “sort by distance” feature to look for jobs near her current job did not provide relevant information and she doubted whether the system had done any work or prompted her to check on maps.

8. Kiran and some other users were unsure if they recognized the job location because it only included the city and not the location itself. They thought this was strange because they expected the location to be listed with the city name.

9. Shrilekha had trouble finding her applied job in order to track her application. She struggled to locate it on the first try after applying.

After the insight are gathered we sat again together to validate the hypothesis. Here is the list of Hypothesis which got validated from Primary Research:

Hypothesis validated from Primary Research

💎While validating our hypothesis, we realized that we needed to prioritize the problems that we identified. Two reasons for that.

1. we found some major issues, such as users being unable to find the “My job” option, which needed to be addressed.
2. we were under time constraints

After discussing the situation, we decided to leave the filter page from our flow. We felt that the other problems were more important and had a higher impact than the issues on the filter page. So, Goodbye filter page!🥹

💎By the end of the research we get to know two things:

1. We are making progress in the right direction. Most of our hypotheses were confirmed by the end of this research.
2. We were able to identify which hypotheses did not hold up to our research, and we used this information to make adjustments to our plans.

🌟LEVEL 3🌟 — The Solution

Now we had validated our hypothesis. it’s time to develop solutions for the hypothesis.

Things we did here👇:

• We all sat down and started making the “How Might We” questions — to come up with a wide range of potential solutions rather than just one or two options..
• We strictly focused on the problem statement and the problem we are trying to solve keeping the research alongside.
• We were careful not to simply give users what they asked for, as we were trying to solve for the broader group of users.
• After framing the HMW questions, we used the Crazy 8 method to generate a range of possible solutions.

HMW question and the possible soutions

3.1 Wireframing:

After this process, we all converged on the ideas that were relevant, significant and practical. we discussed and finalized the features to be added to our app. Then we created wireframes to incorporate our ideas into the existing screens.

• We took some inspiration from Competitor apps

For e.g.: To solve the user’s struggle to find their applied jobs, we found that LinkedIn jobs were doing a better job by providing a separate tab to know the details of their Applied jobs. So we decided to use that idea in our app. Due to the short amount of time we had, we felt it was wise to borrow ideas from other apps that had already been tested and proven to be effective.

• We also used Pinterest and Dribble to create a mood board for our UI wireframes.

3.2 Making the UI screens for Usability testing:

Here comes the exciting part. The part where we get to see the results of our hard work over the past 1.5 days.

As the person in charge of the UI design, I prepared a plan to complete this quickly, as we had limited time available.

💎Plan A:

• Creating basic UI before starting work on the UI design.
• Create an existing screen of Apna first and then revamp it according to our idea.

The plan was to create existing icons, components, navigation bar, etc., whenever I had free time before coming to this UI stage to make our work easier. And guess what, it actually paid off😁. When we came to this UI solutioning process it made it easy for the team to straight away focus on developing solutions without worrying about the basic UI needs. Plan A’s first half was a success.

However, the second half of plan A did not go as expected, as it took longer than anticipated to create the existing screens. So to address the panic monster(Time), we revised our plan A to Plan B.

💎Plan B:

• To create the solution straight away instead of recreating the existing screen.
• Create a mini-design system to make our life easier

Instead of recreating the existing screens, we immediately began working on developing solutions for the existing screens. While my team was working on creating the screens, I worked on creating a mini-design system of reusable components, including colors, text styles, iconography etc. This made it easier for us to make changes to the screens if necessary, as we could use the design system to quickly and consistently update the UI elements. This helped us to be more efficient and effective in our work.

As a fan of Brad Frost’s Atomic Design and Urban company’s Align DS, I tried to follow their ideas in our mini-design system. I organized our design system into atoms, molecules, and blocks as components and we used instances of these components in our files. I tried my best to make everything clear and organized within the available time.

Mini design system — ATOMS

Mini design system — Molecules

Mini design system — Blocks

Mini design system — Style guides

The most exciting screen I worked on during this process was the home screen with the “My jobs” and “Jobs for you” sections. This was a completely new flow compared to the existing app, and it was exciting, challenging, and fun to discuss and finalize the design as a team.

Here are the screens we created and the reasons behind each of them:

UI screens are ready. Now we are ready to conduct usability testing on the initial UI screens.

3.3 Usability testing with the redesigned UI

With our revised UI screens, we conducted usability tests on both previously interviewed users and new users to gather unbiased insights. We were interested in understanding the following through the usability tests:

1. Whether the changes we made had an impact on the user experience.
2. How users were interacting with the new changes, and if they encountered any problems while using them.

👉As we expected, the usability testing results showed that all users were able to complete tasks naturally. Most of the changes received positive feedback, particularly the introduction of the “My jobs” section, which users found to be very useful and easy to navigate. (Is there any feeling greater than getting validation for your hard work🥺)

Here are all the insights we received from the users based on which we made some changes in the flow:

Mapping usability insights with the respective screen

During the usability testing, in addition to positive feedback, the users also pointed out some minor flaws in the screen. We took their feedback into consideration and made changes where feasible.

👉Some examples of the issues that were identified and addressed include:

1. Confusion about whether the “x” button in the “My Jobs” section cancels an application or removes it from the applied list.
2. Difficulty reading the small font size for distance information.
3. The need to go back to the home screen to view or track an application after applying for a job, which users found time-consuming.

We realized the importance of regularly gathering user feedback and making necessary changes to ensure that the product meets their needs and provides a good user experience.

3.4 Final UI

We discussed the flows among us and decided to update our UI wherever it is feasible. And this is the final UI after the usability testing:

And here is the Final revamped job search flow of APNA🤩:

Final revamped job search flow of APNA

YES!! We were able to pull off the project within 48 hours.🤩

But the hard work paid off, because not only did we finish on time, but we also impressed Anudeep and received positive feedback in the final review session. It’s all thanks to the team’s hard work and dedication.

👉You can see the glimpse of our final review session Here!😁

3.5 If given more time, we would have:

• Improved the user interface design more better.
• Spoken with more users to gather more insights about their problems and needs.
• We would have also solved the problems with the filter page.

3.6 Here are the key learnings from the project:

Technical takeaways:

• UX design involves both addressing user needs and achieving business goals. It’s not about solving user’s problems only.
• It’s important to stay focused on the problem statement and business metrics, which are inseparable.
• Taking the time to thoroughly understand the problem is crucial and can help with completing 80% of the project.
• Having a strong sense of purpose and motivation can help drive the project forward.
• The power of “diverge and converge” — Dividing work among team members based on their skills and allowing them to work independently. After a set amount of time, the team members come back together to discuss the status of their work, any problems they are facing, and any insights they have gained. This allows for the efficient use of individual skills and helps keep the team aligned and informed.
• Importance of keeping team members informed about progress and ensuring that everyone is on the same page.

Personal takeaways:

• I never had the chance to work in a team at my prior jobs because I was the sole graphic designer working alone. But here I get to know the power of working and solving something as a team. Working in a team can bring a diverse range of perspectives and ideas to the table, which can help generate new solutions and improve the quality of the work.
• Understanding the heart of what you do, can help you stay focused and committed to your goals.
• Trusting the process of finding solutions, rather than immediately focusing on finding a solution, can be enjoyable and lead to better outcomes.

Thanks for taking the time to check out my case study! I would love to get your thoughts and suggestions on it, so if you have any, please don’t hesitate to share them. Your input would be super helpful and greatly appreciated. Thanks in advance! 🤗

👉Say a “Hi” to me on LinkedIn

👉You can also send me an email at jeganathan8938@gmail.com

“Don’t forget to give the “👏” button a little love! (Yes, It’s the one that’s practically begging to be clicked near your thumb 😁)”

Thanks a lot and Cheers!🥁