When we wanted better data, we designed for it
“So you say there is nothing to track our reach in different domains?” I asked.
“Not really. I have an excel sheet where I note down everything. But can it be updated easily? No. Can someone else use it easily? No. Can it improve our SEO? No. So, now you understand the problem?”, said Ayush.
Ayush is a product manager at HackerEarth Sprint which conducts numerous innovation campaigns (popularly known as hackathons in developer community) every year. Each of these campaigns has created an impact in different domain, industry or technology; a significant number of these campaigns are managed by the Operations team (Ops team) at HackerEarth. The Ops folks have an administrator portal called HackerEarth Sprint where they monitor and manage these campaigns.
Recently, the team realized that it is important to classify each of the campaigns conducted so far into its relevant domain, industry and technology so that the reach in each of these categories could be measured. Better data would mean better analytics, better SEO and better tracking. However, the task was not limited to classifying the past campaigns. The team needed a scalable and sustainable solution.
To fulfil this requirement, a feature was requested that would allow the Ops team to classify (or to put it simply, tag) every campaign into relevant categories on their own and without having to write any code.
This story is about the design process of this feature and the lessons I learnt from it.
Conditions in the process
For any campaign, the tags that could be added were divided into three verticals–Industry, Domain and Technology. The combined number of tags available in each of these was more than 100. Also, it was given that the option to add these tags would be provided in a separate tab in the left navigation of the portal. So, my playground was the area inside the tab.
The Process
As there were a large number of tags in the list, providing a feature to search and add tags was my first thought. However, when I talked about it with Ayush, I realized that it was not necessary that the Ops team members searched the tags by the exact names as were given by him. So, having a list of all the tags to choose from was also necessary.
Now, the question was about prioritizing. Which way of adding tags should be prioritized, “Search and add” or “Click from list and add”. The use cases were like this:
The “search and add” approach was keyboard focused and hence, would yield higher efficiency in repetitive use which was to be the case with the Ops team. Thus, we chose to prioritize the “search and add” approach.
Moving on with this approach, I designed this view
However, there was a problem with this view, that the primary button i.e. “save” was placed before the other option to select tags i.e. “click and select from all tags”. The save button had to be the final and thus, the last action of the page.
Also, it was necessary to show the save button right next to the selected tags to ensure that the user could see the tags added while clicking it.
To prevent this illogic, I designed another version
This was again confusing because the selected tags were being shown twice.
Confused about this flow, I went to Anand, a colleague at HackerEarth. Prepared to explain my problem in a full detail, I placed my laptop on his table and waited for him to utter, what I thought would be his first sentence “What is this?”, after which I would explain the problem to the tiniest of its details like a talented orator. However, the moment he had a look at it, his first question was “Why do you need a save button in this design? Can’t we auto-save it?” The question dawned on me like a eureka moment. “Why didn’t I think of it? That would solve all my problems!”, I thought, excited to pick up my laptop, run back to my desk and make the changes. However, I held my excitement and stayed, to listen in detail, what more he had to say. The rest of the feedback he had was mainly centered around asking what the design was for and explaining what the benefits of auto-saving would be.
Thanking him for his eye-opening feedback, I quickly made the changes and came up with this version:
This new and improved design with auto-save was accepted well by the team. Aritra, then a software engineering at HackerEarth, developed the feature and passed it on to Ajay, a QA engineer at HackerEarth. Ayush, meanwhile had classified all the past campaigns so that the data could be fed to the system. The feature was thus launched.
In retrospect
Through this project, I realized that having feedback from someone outside the project team leads to invaluable insights. Had I not asked Anand about the problem, I would have been stuck in the “Save button” issue. So, since this project, I have made it a habit to put my whiteboard in the middle of the office where everyone passing by can take a look at my thought process and can give feedback if needed.
During the whole process, keeping everyone on the same page was one of my top priorities. To achieve that, I spent a significant amount of time writing detailed and precise update emails. However, a lot of time was also saved by using the Craft plugin in Sketch due to which I could share an interactive Invision prototype before every meeting instead of showing just static images.
The whole process of design and development took one week and a half. That is the beauty of working in a startup culture–you can see your designs going live in production in almost no time.
The Ops team now uses this feature to classify the campaigns. Ayush has thought of an ingenious name called “Classification” for this feature since that is more intuitive for the Ops team. HackerEarth now has a better, more Ops-friendly way for the classification of its campaigns, both past and those which are to come in the future.
If you liked the story, please click the “Claps” button as many times as you like. :)
Thank you, Dhruv Bhanushali and Prafulla Anurag for editing the story.
