Introduction
This project aims to explore and create universal commenting user experience (UX) design patterns for various C3.ai applications, with a specific emphasis on the Anti-Money Laundering (AML) application's use case. The goal is to design a standardized comment UX pattern and its components, accompanied by thorough documentation that other designers can refer to
2022 summer internship project @ C3.ai
3 months | Jun 2022 - Aug 2022
I spearheaded the commenting design project working closely with two designer mentors and a product manager. I led the development of commenting patterns, crafted interactive prototypes, and thoroughly documented the design system
Product Designer | Soo Hwang
Product Manager
Design System Designer
Application Engineers
Process
Explore and define the current comment design pattern's problems
Conduct user interviews and research analysis on comment pattern
Create a visionary prototype with three different design options
Create a final design iteration with the design system compliances
Create design documentation with interactive patterns
define problem
lack consistency in the patterns, interactions, and components of commenting. Given that commenting is a pivotal feature across multiple apps, the need for consistent and standardized commenting patterns has become increasingly crucial for both the design and engineering teams
A comment serves to showcase descriptions, discussions, notes, and user feedback, usually consisting of just a few lines. However, the existing C3 applications.
DESIGN goal
To address this question, I established three design goals aimed at improving the usability of the commenting design pattern. Throughout the design process, these principles should be given priority and adhered to in order to develop standardized design system patterns and documentation.
The commenting pattern should exhibit consistent UI components and behavioral patterns.
The pattern and documentation should be applicable across multiple applications.
The pattern itself should be clear, easily understandable for everyone, and focused on the user.
design decisions
For the commenting style, I explored a total of four ways of design style explorations. Each style possesses distinct characteristics, prompting me to explore multiple iterations and determine the most suitable style for commenting patterns and behavior. Below, I have organized the pros and cons of each style that I discovered throughout the iteration process. Hover on each design style to see its pros and cons.
In-line Top Input
In-line Bottom Input
Take-over modal
pop-over modal
Approach
To finalize the pattern style, I facilitated a design critique session with other application designers and project stakeholders. During the session, I presented an interactive demo, conducted a brief usability test, and collected feedback.
Stakeholder's QUotes
"The In-line and Take-Over style UI can leverage existing components from the current design system. On the contrary, the pop-up modal style lacks any components or interactions from the current design system requiring additional technical implementation and the development of specific components."
" I personally prefer the In-Line style as it aligns better with the natural flow of the commenting feature. Moreover, given our app's use case and research assumptions, comments tend to be around 3-4 sentences in length, and interactions like replies and edits occur frequently."
Why This decision?
It shows the recent comment on the top and is staked in vertical order. This interaction is natural and chronological.
Users do not need to do additional actions for the in-line style, compared to the modal (button in-put) style.
Design components like text field, list, search bar, and buttons are available in the current design system.
design decisions
My second major design decision was about global and page-level navigation. To briefly explain this, there are two types of comments which are global-level and page-level comments. Page-level comments are typically tied to individual pages, involving feedback on specific references or issues. In contrast, global-level comments encompass all page-level comments. During the design critiques, the application designers had some questions about this concept, as shown below.
designer's QUestions
"In *** application, we typically have more than 100 comments in total. In such a scenario, I'm concerned that the comment side panel could become overly complex. How can we address this use case?"
"In the OOO application, we don't have the activity feed on the dashboard. In this case, how can I access the comment side panel in the global navigation?"
Approach
To establish the concept of global and page-level comments, I analyzed the current application's use cases, focusing particularly on the AML (Anti Money Laundering) application. In AML, users are required to comment on a case, which involves multiple pieces of evidence. The global-level comments in AML pertain to remarks about a specific case, while the page-level comments are related to each piece of evidence associated with a case. Through this use case analysis, I can articulate the distinctions between global and page-level comments.
Design Iteration
The global and page-level comments need to have different patterns and interactions. To define each pattern I made the table chart to show its availability of interactions.
Users can navigate from the global to the page-level side panel by clicking a reference in the comment.
Design Iteration
To access the comment side panel, there are two navigation options. First, users can reach the comment side panel when notified through the global notification located in the global navigation. A comment associated with a global-level reference will direct users to the global comment side panel. Conversely, if the comment’s reference pertains to page-level content, users will be directed to the specific page-level side panel.
Additionally, users can access comments through the activity feed component, which features a dedicated section for comments. In the activity feed, users can access the comment side panel or view a specific comment by clicking on it.
design decisions
The final design challenge I encountered arose while developing a practical workflow. Creating feasible patterns necessitated designing a configurable system that could seamlessly integrate with the existing design framework. In the quest for scalability, the original design underwent significant changes, and numerous design decisions were made throughout the iterations. This marked a crucial juncture where I confronted the challenge of maintaining design system compliance while ensuring a high-fidelity design aligned with the visionary design style.
What is the problem?
After talking with the design system designers and re-designed the side panel component with the design system style, I realized that some usability and visibility problems did not match with the visionary design style.
The utilization of the list component in the comment sections resulted in a reduced margin between each comment component, leading to increased complexity in the UI.
The typeface changed from "Inter" to "Gotham", text content looked more compact and showed less hierarchy between the ranges.
According to the current design system, the search bar, drop-down selection, and text fields share similar styles. In comparison to the visionary design, which distinguishes elements by changing the background color, the design system style exhibits less visibility and information hierarchy for the search bar and input fields
Design Iteration
To clarify the hierarchy, I relocate the search bar at the top of the comment list. This shows more clear hierarchy that the search action applies to the comment list below.
To solve the typeface style difference, I use less transparent color (toned-down) in the subheads and additional comment information to highlight the comment contents.
Make more margins between each component and subheads of the comment to decrease the complexity of visuals
Instead of using the "Filter" button, separate filter and sorting options to make the user o easily understand it and create a clear hierarchy that filtering and sorting apply to the comment list.
Final Deliverable
For the final deliverable, I crafted a design system and pattern documentation for commenting that other designers and engineers can consult whenever they wish to integrate the commenting feature in the future. Additionally, I created UI sticker sheets in Figma, allowing designers to conveniently copy and paste the commenting patterns. Below, you will find a summarized version of the commenting documentation. Expand each tab to view the contents of the documentation
Commenting Documentation
A comment displays descriptions, discussions, notes, and user feedback. They are typically short, about a few lines long. Commenting exists in the side panel with multiple different components. The side panel design can include a search bar, buttons, an in-line text field, or comment lists. Comments are usually used when a user has questions or concerns to communicate with another collaborator or simply a quick note for themselves to get back to. In this document,
Here is the list of UI components related to the commenting feature. You can see each component’s anatomy, how to use them, and the implementation checklists in these lists.
Default: The primary type of comment component. The component includes the commenter’s user name, hyper reference link, the time stamp of the comment creation time, and the comment itself.
New: For the new or unread comment, the blue dot sign will exist beside the comment user name until the user gets into the side panel and read the comment.
Highlighted: For the search result, the search keyword would be highlighted.
Selected: When the user clicks the comment, the background color will be changed to a lighter color and show that the comment is selected.
Global Side Panel
The global side panel includes every comment that belongs to the global content. Compared to the page-level side panel, the global side panel includes more comments across different pages, so users can search and filter down the comment. When users add a comment in the global side panel, they must select the references (page). If the comment does not belong to any page, the user can choose the reference to the global content; in AML, it is called “Case Title.”
Page-level Side Panel
The page-level side panel is used for the specific page-level content, including the comment belonging to that content. According to the use case analysis in AML, the page level side panel does not have a search bar, filter, and sorting options because it usually contains less than 10 comments.
The purpose of the activity feed is to inform the users of any changes to the clients, accounts, cases, new comments, etc.With the tap above the feeds, users can navigate to specific activities.
Here is the list of UI components related to the commenting feature. You can see each component’s anatomy, how to use them, and the implementation checklists in these lists.
Users must select the reference (related page) in the global side comment panel. However, if the comment is not related to the specific reference, they can choose “Case title,” which means global level comment, not stick to a particular reference.
The “Edited” status should be next to the time stamp in the single comment.
The confirmation modal is required after the user hits the delete button.
It is a text-based search, the search activity is completed on the same page, and the text input consistently changes the search result. The search keyword is highlighted in the comment.
The CTA button changes to “Submit” → “Reply” for the replying comment.
project wrap-up
These are the three main takeaways that I learned through this commenting pattern project.
Exploring a UX pattern has some general rules, but sometimes, it is good to break them. Breaking rules can bring creativity and the exact solutions to your use cases.
In this project, I received many insights from the feedback session. However, when you are looking for feedback, clarify the point that you are looking for, and deliver the detailed context of the project.
It doesn’t have to be complex, it can be just a few words and a single sentence. This is helpful for you to deliver your design decisions to stakeholders with evidence and confidence.
project wrap-up
The next step for this project is the implementation of the UI component. To achieve the goal of being an accessible and applicable guideline, a detailed and feasible UI demo should be required.
