Recently I got an opportunity to design an experience for a Design-a-thon Palette, the annual design-a-thon organized by IEEE-VIT. I have been procrastinating on this case study and a couple of other projects for a while now but I’m finally getting to them all one by one, starting with this one!

In this article, I will cover my experience working in multiple teams for the event and take you through my journey from rough sketches to the final product. I hope to show you the various challenges we faced during development and how my team overcame them, making sweet memories in the process.

So as some of you may know, a Design-a-thon is an intensive design event where the participants are presented with a problem statement that needs To be solved by designing a product using a human-centric approach. Funnily enough, our design-a-thon was definitely not just human-centric, featuring aliens, witches, demons, and more 😂

With that introduction out of the way, let’s get into the case study! 
Beware, it’s a long one so get your cup of coffee and let’s dive in ✨

What is Palette?

PALETTE ’21 is the 4th edition of the prestigious design-a-thon conducted annually by IEEE VIT. While the last three editions witnessed amazing graphic designs and web designs, this year it was a 48-hour long design hack based entirely on the concepts of UI & UX.

It’s a solo/team event where participants are presented with a problem statement generated by our unique problem statement generator. Palette has 3 rounds of intense judging, with the first two done by our IEEE team and the 3rd round by industry experts.

For more information about Palette visit:

Palette'21
Date: 27th May 2021

Total Registrations: 500+ registrations

Countries reach: 65+ countries

This was going to be one of my best projects with IEEE VIT.

Palette logistics:

Project requirements:

• UX flow of the event.
• Branding, graphic assets
• Email templates (Design and generating code, discussed later in this section)
• Design-a-thon Portal
• Landing page

Time limit: 2 Months

My responsibilities:

• Designing UX flow for the event
• Landing page and Portal Designs
• Branding and marketing assets
• Email template generation(Through Figma Plugin)

Too much to discuss in one blog?

Perhaps. But I can assure you there won’t be a dull moment and truly value your time and patience :). Now the question is how am I going to discuss all this in one case study?

I will divide this case study into 4 parts:

Part 1: Basic organization and event flow, and talking about challenges

Part 2: Discovering solutions, and key takeaways at the end.*

Part 3: Setting up branding and vibe of the event.

Part 4: Designing Email Templates and conducting effective Email campaigns.

I’ll be further breaking down each part into different blocks. Feel free to jump over to any stage or process/section for easy navigation.

I have concluded most of my learning and some design gyan(knowledge) in Part 2 of my blog series where I also discussed some of my design key takeaways in short. So keep an eye out for that!

Time to board the roller coaster

Part 1 of “How to design your own Design-a-thon”:

Project Goals: Make a design-a-thon portal to help participants navigate easily in one place.

Ideation and Brainstorming

• Every year, the team of Palette faces the challenge of making their edition better than the previous ones. It was, even more, intimidating for my team owing to the resounding success of Palette ‘20.
• So we took the bones from previous editions of Palette and spent hours on end fleshing out ideas for an improved flow and better user experience
• This brought us to the proposition of creating a design-centric portal for the event. But with 2 months left, was it feasible? 
  We knew it would be a demanding task, had countless meetings to discuss the same, but we knew in our hearts that this was the way to go and so we dove in, ready to put in every ounce of what we had. And it was every bit as gratifying as we’d envisioned it to be!

Research and Understanding

The new flow initially seemed challenging to integrate, but I started by building my initial base.

Research

My research started with gathering insights from previous editions of Palette and analyzing the feedback. I started my competitive analysis along with it from current portals such as Devpost, Devfolio, and other similar platforms.

In my research, I didn’t find any design-a-thon that focused on a design-centric portal.

My main goals for research revolved around the following parameters:

• How would multiple round submissions be conducted?
• Team formation and networking: This was one of the most interesting parts of my research.
• Design centric and personalization, (Dashboard designing research)
• Re-inventing problem statement generator
• How to keep hackathon beginner-friendly as well as for experienced.
• Most importantly — How to keep users engaged Before, During, and After the hackathon

I was all set and excited for my journey, but there was so much more to come 😳.

Let’s jump into my UX process

I wanted to make the user experience like never before. My design process is all about pen, pencil and connecting different dots from insights collected, and making a sweet story out of it.

Analyzing the story, exploring different edge cases, and then vibing to the natural flow of the product.

I think of navigation as smooth flowing water reaching out to its destination without any breaks or barriers.

I planned the following tabs in mind on the portal:

• All three rounds submission and updates through the portal.
• Team formation and joining
• User Dashboard
• Event Overview (Summary and all help needed regarding event)
• Enhancing Problem Statement Generator Experience
• Help and contact section

The 11th iteration scrap off story

I was trying to figure out what will work, what won’t work. IEEE design team helped me all along this journey to figure out the necessary stuff needed whenever I was going off the track.

When I start ideating over with pen paper, things get soo messed up, but these small dots when connected reveals a lot of stuff.

My focus was revolving to improve the experience for designers attending this event and present them with the relevant information needed.

Onboarding process:

Onboarding is a process where your users get to know more about your product and achieve their goals quickly. We also had a landing page before the main registration helping users know more about the event. I had to focus more on the registration process.

Goals

• Making registration process simpler
• Giving more personalized experience to the user

After some sketching and storyboarding I came up with the following flow:

1. Social/Manual Login/Register

2. Greeting message and get started

3. User email verification

4. Getting to know the user

5. Team formation conditions(will talk later in the section)

6. Success message and dashboard tour

1. Getting to know users: This step had details like tools, skills, and discord username required for team formation and teammates finder feature along with verification on discord. These details were good to go for the next iterations.
2. Teammates: Team formation and solo participation were allowed during the hackathon. They can either create their team or enter code and join a team. We gave them a switch with the help of which they can activate looking for teammates, which we will see in the Dashboard design process.

3. User verification: After internal discussion, we realized not having a manual login can have a lot of benefits in the process:

1. We can eliminate fake or spam accounts to a greater extent.
2. We can remove an additional step for verification, too.

We removed the verification and manual login and moved ahead with the next iterations.

Likewise, we also had stepper integration to let users know what’s next for them. We also took care of edge cases possible like:

• What if a user reloads the page in the middle of the process. This edge was communicated to developers and hence was resolved. Hence, they continue from where they left.
• There was another problem with selecting the number of tools and skills, as there was limited space and might confuse users on selection. Later we will see how we solved this problem.

These were some most prominent edge cases, and hence this was good to go further visual stages.

Dashboard:

My main aim with a Dashboard portal was to give a complete experience and necessary things, so they won’t have to wander around other places for PALETTE.

I started with making a story out of it and how things will flow from onboarding to the end of the event all through one portal. And thus I began my research on design-a-thons and general hackathon portals.

Based on story-boarding and some research, I penned down the following flow.

Now there were some challenges:

• Team and solo: Conflict management was a high-risk task and we had to ensure that we prioritized things well.
  For teams, we found the following potential problem areas:

Scenario: User A registers himself and a default team name “DesignPals”. Suppose a second User B also registers his default team as “Figmates”. The team formation process is going on and User A sends a request to join a team of User B. In that case, User A’s team has to be replaced with User B’s Team if the join request is accepted by Team B. But what if User A, leaves his team again and his default team name “DesignPals” no longer exists or has been taken by someone else? What default name could we assign the user?

After a lengthy discussion on what is ethical with design and the dev team, we reached a simple solution using the method that is followed by various companies like Devpost and Devfolio. It was a pretty generic solution, but it was to warn/inform users of this situation in the future. There could be many more solutions to this, but with our time-crunch, it was what worked best for us.

T-2 iteration:

I came up with the following important things on the following reasoning:

• A user needs to have quick team actions to invite or leave.
• A quick timeline for the event was also necessary, as this was a high-priority task as well as a banner to engage and update the users.
• And a banner to keep users engaged and keep them updated regularly.

What all other tabs were included?

1. Round system informing users of their current progress.
2. An internal guide to PALETTE
3. Design resources to help beginners to get started quickly and find assets for their design.
4. Support and help
5. Problem Generator
6. Teams and networking

A lot of work was covered in a very small duration due to the limitations we had with the time frame. The devs needed time to work on the designs, the portal had to be tested thoroughly and we also had to set aside some time to work on any issues that might crop up.

I was in regular contact with my mentor, for feedback and suggestions whenever required. This was an incredible experience as I got to learn a lot from him and he was able to point out the UX flaws that I had missed. It also was very fun to just sit on the Figma file and brainstorm for hours with such an accomplished and passionate designer.

This was another iteration made on the thinking that the problem statement should be visible to users on the home screen and it also provided a better way to declutter the design caused by the responsiveness in the previous iteration.

This initially seemed like the best solution to me, however, after discussing it with my mentor, I realized that this was leading to an information dump on the user and a lot of unnecessary focus was being placed on the teams. Hence, I had to find a better way to solve this.

Responsiveness

Knowing that the participants might want to access the portal on whatever device they find most convenient, we planned on making our interface responsive for all devices.
However, as the developers worked on the responsiveness, some very interesting issues cropped up.

On the web, we had pagination integration for teams’ pages. We had something around 40–50 pages, with teams of 6–9 on each page. I planned out a design with an infinite scroll for smaller devices, but it came with a tech cost. For the web, we had to make an API call for each page to get the team list one at a time. But this was not the case for mobile phones. In infinite scroll, multiple API calls had to be made to fetch a huge list of teams, and hence after reaching some 100th team, the performance of the phone would be degraded significantly due to memory allocation issues caused by displaying all the teams on a single page. Hence, a web portal seemed more feasible as it only needed a single API call for each page as compared to multiple on phone

Wanting to resolve these issues, yet constantly aware of the deadline looking over us, we had to compromise on the responsiveness this time.

So now that we’ve outlined the issues that existed before working as well as the challenges that came up during the process, it’s time to take a water break. 
You’ve earned it for being such an incredible and patient audience.

Be sure to hydrate yourself, get a snack, and prepare another hot cup of coffee. I’ll see you at the other end of this break 😌 with part 2 of ‘How to design a Design-a-thon’ where we will see the best possible solution to our challenges, a short tale, and many important key takeaways at the end.

See you in Part 2 😋.

How to design your Design-a-thon? [Part-2]