Designing for a data-heavy platform

Case-study for WebEngage’s marketing automation product design

Tejas Bhatt
Prototypr

--

WebEngage redesign and design system
Journey from wireframe to interface

If you are reading this in December 2023, good to meet you. 👋 You should follow me on X (fka twitter): space_dacait

Read this article in Chinese, translated by jeremy0417https://designtongue.me/data-heavy-ui-design/

Onwards!

WebEngage is a marketing automation platform that operates out of Mumbai and US. They service over 38,000 happy customers engage 180+ million users monthly. Their growth demanded they expand to markets in US and Europe.

WebEngage came to us with a clear road ahead charted out. Their use-cases were elaborate and the product offered extensive features. They were taking a different approach to analytics. While other similar products focus on reducing the information, WebEngage wanted to offer lot more insights. That made our job of designing the product both easy and challenging at the same time.

Anti-minimalism

There is a strong trend of reducing complexities in design. That works in consumer apps with single and simpler goals. But when you are designing for enterprise products, you cannot reduce the number of features or simply do away with complex use cases. Will an aeroplane-flying experience become better for the pilot with only single lever for take-off and landing (obviously with a stories feature thrown in 😛)? I am guessing not.

Stories? D’oh! From Giphy

We did not want to reduce features to make WebEngage like other apps. This was the opportunity to improve the information architecture and prioritize features while also keeping the competitive edge.

Having said that, the visual language of the app is still very light and minimal. The goal was to let users focus on the information, not chrome.

Process

The amazing team at WebEngage gave us detailed product specs and wireframes. That gave us an easy access to their vision of the product. After understanding the core features, we delved into creating a visual language.

We started with working on only a few screens at first. This was to establish a design system. Each element we designed, instantly became part of a living style-guide. This helped us create a modular component library in Sketch. This wonderful article by Emin Inanc Unlu on using Sketch resize to streamline components helped a lot while creating the library, as did this article by my colleague Wolfram.

Design System

For the constantly growing product, we considered how the design could be extended for future use. We needed to think about enabling the client to continue scaling the design on their own.

Our approach to the design system was more like that of Google’s documentation their Material design guidelines. Since the stake-holders of this design are going to be designers and developers, we went with a verbose documentation.

The Design System is elaborate to explain rational behind decisions and the dimensions. Totally un-Dribbble-worthy. 😉

Grid, sans grid

Dashboard designs have a dense information structure. Using a strict grid is often not the best approach. Instead we created rules for margins between elements and how elements should stack.

Content Out

The design uses content-out principle, as opposed to box-in. As mentioned before, instead of sticking to a grid, we are using content as our measurement. After defining a certain amount of white-space around elements, the rest of the design took shape organically around the charts, tables and rest of the content.

Colour Theory

When you are displaying a variety of content on a screen, you have to be careful in selecting the colour scheme. WebEngage had tons of charts and graphs to show different stats. We researched best practices for data-viz colour scheme and found some amazing resources.

That’s more likely to get some Dribbble ❤️.

Typography

Typography is one of the most fundamental component of design. For apps with a very wide user-base, it often meant that you had to resign to native font-stack (Arial 😔, Helvetica 😏). Good for us, now the operating system typeface game is up, up, up. We went for a font-stack that would render like a native app in most browsers/operating systems.

font-family: -apple-system,BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif; 

The method to implement this font-stack has been well-documented by Booking.com’s post.

Using system fonts also allowed us to use a spectrum of font-weights, which otherwise would have been hard (but will become lot easier with embedded fonts when variable fonts gets implemented).

Actions and Buttons

Early on in the process, we made the decision to assign priority on scale of 1 to 5 to actions and buttons, 1 being the lowest and 5 being the highest.

Information and action prioritisation on wireframes
  • if the priority was 1, those actions would be combined and pushed into drop-downs.
  • if the priority was 2 or 3, the actions/buttons would be in form of icon-only elements with tooltip.
  • higher priority actions would have Text-only links or buttons. This would let the users take critical actions without guessing the meaning of icons.

We avoided buttons with icons and text both together to avoid redundancy.

Detailed instructions about the usage of buttons.

Visual Hierarchy

We designed all elements with two-factor distinguishers. What is a two-factor distinguisher you ask? For example —

The element in hover state above is different in colour and also has a background. This type of two-factor distinguisher reduces the cognitive load on users as it is now lot easier to tell the two states apart.

We used this principle across the entire app. So adjacent elements have distinguished styles establishing proper visual hierarchy.

Designing for Data-visualisation

Data-visualization over large-scale data is hard because one tends to run out of colours to use to denote data. We solved this by combining multiple data-points into ranges in tight spots.

Responsive-ness

The responsive design concept is most talked about to accommodate smaller screen-sizes. But if a product is targeting large and larger screens (1280px wide and above), we need to think about how to use the extra space to show more information.

(L) chart at 1280px width, (R) same chart expands to show more data-points when more width is available.

The Fun

How do we add some elements of fun into this mix? We explored some options to add bit of humour to the design. However, this idea was ditched to make these screens not stand out much.

The 80’s kids would love that TV reference.

Wrap up!

After over 2 months of collective hard-work, we delivered not only the product but a scalable and sustainable system for WebEngage. The product turned out in a way that both they and we are proud of. Give the product a spin, but be aware as the implementation is still under progress.

What they said

One of the key metric of a successful engagement is what your clients feel about your work, after all the hard work and thinking that goes into collaborating with teams. Here’s the kind words from the fine folks at WebEngage.

Tejas has helped us design a top notch SAAS product which competes with some of the best in class SAAS products. He has been instrumental in driving the UI/UX of the entire dashboard together with the product team at WebEngage. When we started the project, one of our main objectives was to build a component library which would help abstract the future design efforts. Tejas has created a comprehensive component library for us which basically means that any new page on the dashboard now gets designed in minutes. It has been a great experience working with him and I would strongly recommend Tejas for any design related project.

Arpit Rai, Product, WebEngage

Tejas worked with us at WebEngage to revamp the entire dashboard from a UI/UX perspective. We’re thoroughly impressed with his quality of deliverables and the high design standards that he has. His strong attention to detail along with his ability to always think from a customer’s point of view, has helped in building a product we’re all proud of. The initial response from our customers for this dashboard has been highly positive.

— Avlesh Singh, Co-Founder & CEO, WebEngage

Arpit also wrote about the process of creating the Design System as a product manager. Give it a read!

Thanks for reading so far. We are 3 Sided Coin, a small design studio from India. We write new content on our blog, Fox Pass. You should subscribe to our quarterly newsletter.

You can follow our in-progress work on Instagram, slightly longer posts on LinkedIn, and quick shares on Twitter.

--

--

Experiments with things with the amazing folks at 3 Sided Coin. Twitter: space_dacait