Knak: A Case Study

A UX evaluation, interface redesign, and front-end refactor

Knak is an enterprise email creation platform built to help large teams build on-brand emails faster and more efficiently than ever before.

The Challenge

Knak grew and developed their platform in a rapid fashion common with successful software companies. As a result of their rapid growth, and by prioritizing customer needs, various areas of their platform were beginning to experience divergent designs among some areas of the app. In addition, they began to accumulate technical debt in their front-end code.

Areas of Concern

• Inconsistent interfaces
• Front-end technical debt
• Lack of design patterns

Primary Goals

• Create a consistent interface for all areas of the app
• Update and streamline the front-end code to pay technical debt
• Create a set of design patterns for consistent branding

Usability

As an ongoing part of the interface updates for Knak’s platform, I tested each new feature against a set of usability heuristics as defined by Neilson Norman Group*. To assist with this work, I used the browser extension UX Check to evaluate each area as well as the aXe browser extension to test against WCAG usability compliance requirements.

Code Quality

Writing good code helps ensure maintainability as well as scalability for the future. As a part of the refactoring work I did, I chose to apply a strict CSS Linter through stylelint.io, using a custom configuration designed for readability, consistency, and rapid writing of styles (example shown below).

User Research

Working closely with the Knak team throughout this project helped give insight into the customers and their perspectives while using the product. The research I gathered provided knowledge that drove the interface updates, enabled me to consider their context while building interactions, and highlighted the problems they had that the product was designed to solve.

What I learned about the users:

• Some features were only available to a limited set of customers. This would drive my decision to design optimal interfaces with and without limited features appearing.
• Most users were accustomed to moderately-technical marketing apps. Keeping this in mind, I would ensure interactions would accommodate experienced users first, while maintaining flexibility for more guidance for less experienced users.
• Users spanned a wide breadth of feature requirements to fulfill business needs. Flexibility alongside stability were two top-of-mind necessities while considering each feature throughout the platform.

Layout Redesign

Goals: Familiar, navigable, discoverable

The first high-level issue I noted was an inconsistent layout (shown below) for different parts of the app (one for Customers, and one for Admins). This was identified as a maintainability issue that was a known area of technical debt for Knak’s tech team.

Having one layout with consistent patterns and identifiable architectural areas would give all users a consistent experience as well as enable Knak’s team to continue to create new, stable features for their customers.

The redesign began with simple wireframes (shown below). This pen-on-paper format allowed me to generate multiple ideas and communicate their intent with Knak’s team without investing too much time or energy into options.

In order to create a familiar layout, the decision was made to align both areas of the divergent design into one traditional dashboard-style layout. This included a sticky sidebar and a scrollable content area (see below for breakdown).

Color palette consistency

Goals: recognizable, intentional

Identifying the key brand colors and the theme for the application enabled the creation of a palette of accessibility-tested and reusable colors. These identifiers in the SCSS allowed me to organize styles based on state, response, and behavior.

Colors derived from the brand were selectively used for focused call-to-action behaviors and interactive states. While the palette of colors chosen purely for the app elements reflected a sense of consistency and predictability based on the hierarchy of the element in the interface.

Typography

Goals: readable, usable

The primary goal of font family choices is readability across all expected screen sizes. The naming convention chosen would match architectural choices. This meant choosing class names based on what the element is versus what it looks like. This standard of naming helps with discoverability for designers and developers to easily maintain and create styles.

Once the standards were identified for typography, each repeated interface section with prominent text (such as the title area for each content view) were evaluated, refactored into components and redesigned for reusability and consistency. This redesign occurred alongside the stylesheet refactor that happened behind-the-scenes.

Standardizing the typographic styles helped during the cleanup of the stylesheets as a means of identifying unused classes, inconsistencies for similar elements, and unnecessary specificity for non-unique text. Cleaning up the SCSS files included combining duplicate styles, removing unused classes, and simplifying unneeded complex styles.

Design patterns

Goals: consistency, maintainability, scalability

A strategy for ensuring consistency is creating a style guide. Without adding overhead to an already busy project, using a SCSS variables file can achieve the same purpose. Organized by section of purpose for the app, the variables file can serve as a map for reusable styles.

To ensure discoverability so that the patterns were easy to find and to encourage ongoing use of the patterns, naming conventions were chosen in plain language with full words (no acronyms or shortened names).

The inspiration for the design patterns chosen for Knak were drawn from Material Design. The components for the app and their associated styles were derived from Material Design’s standards for consistent, clean, and intuitive interface elements.

Design Highlight: Navigation

The navigation in this application was originally grouped by user type (Customer and Admin) and their complementary areas of the app. Once the layout had been consolidated into one experience, the navigation was similarly aligned.

Three areas of the navigation stood out as needing attention:

• Taxonomy
• Interaction Design
• Usability Testing

Taxonomy

Taxonomies are systems used to classify and organize things. A taxonomy for web apps classifies items and features based on similarities and differences in the concepts within those features. Information is organized based on how users interpret and search for content.

Some navigation renames were necessary to accurately reflect the content from those areas of the app.

Iconography was evaluated based on patterns widely understood in modern applications. Recall and recognition were both concerns while choosing to upgrade the icons to Font Awesome’s Pro icon library.

Interaction Design

Knak’s user base would begin using the newly redesigned application with little to no hand-holding, and as such, the navigation in particular needed to be predictable and easy to understand.

States for both hovering over items and the currently active navigation item were creating with similar but noticeably different styles.

The hover state of navigation items was designed to have a smooth transition to give a sense of fluid interactivity.

The style difference between active and passive state were designed to be easily recognizable (see the User Search active item in the .gif to the left).

Design Highlight: Forms

Forms are one area of an application that can be easy to overlook during an evaluation of the efficacy of the interface. In Knak’s case, the forms suffered the common pitfall of disorganization.

This lack of an organized layout resulted in a couple areas of concern:

• Poor visibility with information grouping
• Visually distracting

Once the redesigned content area was finished, the final step for a polished title area was to update sub-page titles to display where in the app the user would be while viewing the form. This included state-related titles (for example, the Edit Customer sub-page, seen below), as well as clear, concise breadcrumb navigation to allow the user to return to previous views.

To address the visual disorganization of forms with categorized sections, I designed a new three-column layout for all forms. The left-most column would be dedicated to the form section titles, while the middle and right-most columns would be the consistent layout for all form fields.

These updates created a more readable, navigable experience while filling out extensive forms.

Design Highlight: Switch

Sometimes making small interface changes also impacts unseen areas of the application. Also, sometimes it happens that what seems like a small change is more complex than it initially appears.

What looked like simple CSS styled radio inputs were actually a package brought in that contained pre-made switch components I was unable to modify with simple CSS.

With the goal in mind to eliminate any unnecessary external dependencies, I removed the package and created a new Material-inspired switch.

The result reduced the necessity for external dependencies, allowed customization of the style of the switch, and enabled full control over the interactions and animations.

Design Highlight: Expandable Cards

Occasionally, custom functionality is necessary for a specific feature. In this case, users could enable or disable optional rules, with further customization options once the rules were enabled. On initial inspection, the feature had several conflicting areas of visual priority (see below, left). Unsure of where the eye was intended to follow, the lack of polished focus lead to considerable distraction.

I created a modification on our Material card design pattern to include a clear UI differentiation for an expandable/collapsable card (see below, right).

The new design included a clear separation for the interactive header of the expandable card that also utilized our new Material-inspired on/off switch. A new set of styles for tables was created and used here that included reduced visual noise and effective use of white space for increased readability. Actions were designed to be subtle and secondary to the content of the data itself. The call to action within this feature was given visual and architectural priority to focus the intent of the feature.

With the users in mind, the copy was revisited and modified to include language and actions that reflected the purpose of the feature within the users’ context. Clear, familiar titles were created to reduce confusion and cognitive load while using this feature. Verbs were added as microcopy for the table actions to accompany the icons for clarity of purpose and as accessible benchmarks for the user experience.

Design Highlight: Draggable lists

Drag-and-drop UI elements are a relatively common feature. As such, they have had many years of iterative improvements made in usability that have created commonly understood patterns.

Layout and Design

During the initial evaluation of this feature, it was not obvious in the styling or within any accompanying copy what the intent was or how the user was to interact with the elements (see below, left). The styling aligned closer with a table of data than interactive elements, and had no indicators of a separation between each of the lines of what appeared to be read-only data.

The first priority was to create separate, obviously interactive elements for each of the draggable items. I removed the borders, added a subtle background color, added an identifiable icon and updated each of the action icons to reflect secondary purpose (after the reordering drag-and-drop feature) (see above, right).

To give the entire section a clear purpose, I also included a simple action-oriented title.

Interactive Design (IxD)

Interactions with these elements required careful consideration both during the action as well as after the action was completed. The height of the active draggable element as well as the style reflected in its next potential spot in the list needed to be clear, easy to understand, and quick to manipulate (see below).

As well as creating a clear differentiation between the draggable items (seen above, right — harder to see below in the GIF), the action icons were given a subtle hover effect to enable clear visibility during interactivity of those buttons.

The result of the redesign for the draggable lists was more clarity of purpose for the feature, a faster interaction, and a predictable outcome.

Conclusion

The Knak redesign included many facets of the application. From static design improvement concepts, to improved user flows, to brand new UI layouts and consolidated features. Not least of which was the considerable amount of front-end development work that was needed to pay the technical debt accrued over the course of the fast growth of the application’s user base and customer needs.

Areas of Achievement

• Consistent interfaces
• Refactored front-end to pay technical debt
• A library of reusable, predictable design patterns
• An effective and streamlined user experience

Thoughts from the founder

Pierce Ujjainwalla, founder of Knak

As our app grew, we had several different designers working on different parts of it. As a result, things were not as consistent, and the navigation was way bigger than what it was ever meant for. We needed a better way to make everything accessible in one place and highlight the actions that our users did most often. We also wanted to free up more real estate for what our users cared about and make everything easily accessible in one place.

I think now that we have this new UI in place, our application is best in class for our industry and shows that we care about clean, modern and accessible UX. I believe it much better represents the quality of our application and the value that it brings our customers. I’m confident our customers are going to be really happy with the new UX and make their life making emails even easier than ever before.

— Pierce Ujjainwalla, founder

*10 Usability Heuristics for User Interface Design

From Neilson Norman Group. Read more about usability heuristics here.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.