TapClicks
August - October 2024
Figma, Optimal Workshop, Moqups, Notion, Slack
Sole Product Designer working with Product Managers & Senior Leadership. I was responsible for implementing user research and creating all the wireframes.
Task efficiency increased by 20-50%. Designs were completed in October 2024 and were put into development.
TapClicks is an analytics platform that helps companies track metrics such as advertisement conversions, ROI, traffic, sales, and more.
Users complained that the dashboard widget creation process feels:
1) Overly complex
2) Time-consuming
3) Unintuitive
This is due to overwhelming styling options and disjointed workflows.
Additionally, users often miss or can't find critical settings, which limits their ability to fully leverage the platform’s features.
For this project, I focused on simplifying a complex tool so that users can accomplish their task as efficiently as possible. This was done by optimizing the Information Architecture as well as some visual enhancements.
Below are some of the improvements I made:
Originally, widget settings were presented as a long, unordered list.
I organized settings into labeled groups and introduced progressive disclosure to improve readability and simply navigation.
Users often had to jump between pages & click through a lot of settings to preview their appearance.
I solved this by rearranging the order of form fields and adding visuals. For example, I added plot type visuals so users could instantly preview options without clicking each one.
Users were missing key features and settings. For example this drag & drop.
I introduced signifiers like iconography & hover states, to emphasize key features like drag & drop.
My first step was to gain a deep understanding of the users and product by conducting several stakeholder meetings with the VP of Product and Product Managers. They provided me with a document containing the user research they had already conducted.
They also provide a list of 12 user pain points our redesign had to solve for the 2 main user types:
1) Data Analyst (Power User)
2) Marketing Professional (Casual User)
After meeting with Stakeholders to understand the users and product, I conducted my own research phase to better understand our product as well as the broader market. In my research, I also focused on the idea of "how to create simplicity for a casual user, without harming the usability for the power user".
After discussing research findings with the Lead Product Manager, the Lead PM and I focused on determining the ideal sequence that each form field should appear in as the current sequence didn't make sense for the widget creation process.
I also reviewed multiple task flows to identify areas for improved efficiency, using both traditional flow diagrams, as well as sketches to aid in visualization for when I would present to stakeholders.
After brainstorming some user flows, I sketched low-fidelity screens and digitized them in Figma. I experimented with different ways of displaying & grouping the settings.
One aspect of the design that I had to consider was to avoid confusing existing users with too many new changes.
After receiving feedback on my low fidelity screens, I realized there were several constraints to that I didn't initially consider. I knew TapClicks had a strict timeline for migrating their tech stack, so major UI/UX changes were off the table.
However, I hadn’t anticipated restrictions on smaller updates such as changing setting names to improve learnability and redesigning components such as a color picker (image below).
Through ongoing discussions, I came to fully understand a nuanced challenge we were facing: the widget creation and editing processes shared an identical flow, despite users having different needs & goals in each case.
While creating a widget benefits from a flow that guides users to set up a widget properly, editing requires quick access to settings. Ideally, separate flows would be created for each use case, but the project scope was limited to refining the existing process to address key pain points. Our solution had to balance these differing needs within a single, streamlined flow.
I worked closely with the Lead PM to make sure every setting and feature was accounted for. With a 9.5-hour time zone difference, we collaborated through a combination of video calls, Figma comments, screen recordings, Google Sheets, and Slack channel discussions.
In total, there were 9 widget creation flows that needed to be redesign, each with its own unique settings. I leveraged TapClick's design system and created some new UI components to help create the high fidelity screens. The Lead PM took my designs to get feedback from various customer facing teams in the organization. After a feedback session & iterations, I handed off the final designs.
Because of the redesign, it now requires approximately 20-50% less clicks to create widgets for TapClicks's users.
1) Spend more time on the front-end to understand the product.
This was a complex product and I had some trouble wrapping my head around it initially. This project had a strict timeline so I felt the pressure to progress through the design process as fast as possible. As a result, I only began to fully understand a lot of features, constraints, and user goals as I was designing. I could have saved iteration time if I just spent more time with the product on the front end and really familiarized myself with the pain points. By the end of the design, I felt like an expert on TapClicks, but I wish that happened sooner.
3) Spend time defining the problem and research objectives.
Early in the project, I received a packet of research and proposals already completed by the Product Manager. Because of this, I didn’t spend as much time clarifying the problem or setting specific research objectives, assuming the provided information was sufficient. In hindsight, I would invest more time upfront in defining the problem and establishing focused research objectives.
3) Present my UX recommendations better.
There were instances where I suggested a change, but due to technical constraints, the developer suggested to keep the change for future iterations. For example, I suggested a change for one of the components, but the lead developer informed me that because it was a component, they would have to bring in the component team which would be too much for this scope.
Looking back, I would have presented my case better to include the business case for change. Especially because I believed the change wouldn't have been too much a heavy lift and the benefits outweigh the effort required.
