Appsmith
UX Case Study
The Problem and outcome
I had numerous opportunities to improve the Appsmith design language and assist it in overcoming inconsistencies in the design system, widgets, and layout components for app viewers. Appsmith would like to reskin their core widgets as part of the work so that the styling is improved and made to match the newly proposed core themes as the next set of feature releases for high level App customisation.
I've grown a lot in the last year, and some of my major accomplishments are listed below:
Implemented a design process. This has helped our team establish more structure to how we conduct our work and allow other teams to gain visibility across our upcoming sprints.
Improved usability across the platform. No usability tests were conducted by the product team before dev handoff. Since we established a design team, we have been actively working towards conducting UX research and usability testing on all projects.
Establishing a design kit. This has helped to maintain consistency in the look and feel across different parts of the widgets.
Establishing a design system. This has helped the Engineering and Product teams to understand how and why we choose to implement certain components over others.
I used to collaborate closely with the Product Manager and Engineers to conduct an in-depth problem space analysis in order to identify the problem and find an appropriate solution for them. Going through a quick Sprint review and Crit session with multiple stakeholders also helped me understand the core aspect of the product side goal as well as the issue we were trying to solve. We had conducted multiple reviews with the QA team at the end of the design cycle before handing it off for development and release.
Widgets enable the user in creating the app layout. Users can save data from a database or an API call, as well as trigger events.
Widgets can be dragged from the widget pane, resized, and positioned on the canvas to fit the data they need to display. They also include properties that can be visually edited to set data, change styles, and trigger actions.
In the left navigation pane, navigate to PAGES—> Select the "Widget" Tab—> Choose your desired widget, and drag it onto the canvas. You can move it anywhere on the canvas by simply dragging it around.
Scope - Widgets
Problem with widgets
Key Points we followed
• The primary goal of this project is to make the reskinned widgets consistent with the live product. This means we update the styles but make no changes to the UX/interactions.
• If any suggested UX improvements come up, we will include them in a column beside the re-skin but this should be treated as a stretch goal.
Widgets in Appsmith are crucial in the development of an app. It has around 42+ widgets, each with their own set of features. Because of the characteristics of these widgets, it was difficult to keep the appearance and control panel (Widget property) consistent for each of them. Consider a layout in which a "Form" and a "Text Input" look remarkably separate. This eventually jeopardises the developers' understanding of a widget as well as the deployed App UX for app viewers.
Metric
Customer satisfaction score increases
Goal
Allow devs to customise their apps better
Knowing the pain
Appsmith, as an open source platform, has a vibrant developer community on Github and Discord. It was usually fairly simple to determine what the user pain points were by directly speaking with and interviewing them. We also used to participate on the forum, answering questions and issues raised by them in order to understand how they are using the platform and the types of difficulties they have encountered. Documenting them on notion and find out qualitative data over dovetail. On the other hand, we had to streamline those issue by incorporating feasible product improvements in the form of new features and enhancements
I've highlighted some of the most important areas of work where I assist Appsmith in improving its platform's UX strategy.
My research encompassed:
Understanding the user goals and needs
Uncovering pain points with the existing user journey
Determining the success of the tasks measured
Process
Research
Discovery & Definition
Prioritisation of the issue
Creating Problem statement
Conducting User story and interview
Create
Ideation and Implementation
UX discussion
Wireframe and prototype
Design crit and improvement cycle
HiFi Design and validation
Evaluating the Widget inconsistency
Though it may appear simple, keeping all such widgets in a straight line was difficult due to their open - ended nature of capabilities and mechanisms. We begin by contrasting each widget's possible states and outcomes to those of others. We began prioritising widget teardown in accordance with demand and complexity based on primary recommendations from product managers.
What we have followed
We created a library of documentation for each widget listed after defining the core problems and inconsistencies. This was the first step before we began the redesigning process.
Let's take a look at one of the most commonly used widgets. We received numerous reports of issues with the table widget from github community members, Product managers and QA team which help us decided to address addition UX enhancement during the widget improvement goal.
Tearing down widget : Table
The table widget displays data in rows and columns. You can display data from an API in a table, trigger an action when a user selects a row, and even work with sizeable paginated data sets.
Each Widget has few key element on the Property pane to control and use it on the builder These are
Widget properties
Each widget has its own set of properties, these properties allow you to edit the table itself. All these properties are present in the property pane of the widget
Table data
The Table Data in the property pane allows a user to edit data in the table. You can write an array of objects to display it as table rows.
Events
These are a set of actions that you can perform on the widget like onRowSelected or onPageSizeChange
Header options
These are the options that you can add to the table header. Currently, the following features are available to add or remove from the table header -
Search, Filters, Download, Pagination
Styles
Style properties allow you to change the look and feel of the table. It has several options such as -
Changing the style and size of the font;
Text alignment;
Playing around with the color of the text or cell background.
On the left hand side : Navigation pane
On the middle : Table Widget on the Canvas
On the right hand side : Property pane
Problem with Table Widget
Design Consistency
If you look at the old table widget, you'll notice that the elements within a table are inconsistent with one another. It could be the icon, a typo, or the arrangement and white spacing.
Interaction
Because of its complexity and feature richness, using a Table widget was the most frustrating. Because of lack of understanding how widget can be used, most newly onboarded developers seek assistance soon after attempting to build their first app.
Limited Customization
There was very little scope to customise the look and feel of a Table widget, despite the fact that it was used in a variety of ways to display data or list products, the ability to customise it to a modem app interface was nowhere near.
Reskinning of the Table Widget
We just did not have the choice to completely redesign the table widget because it is the most prevalent widget. It now presents a fresh challenge for us to correct every error while preserving the original flow.
Consequently, we began with reskinning by
Addressing basic visibility and consistency issues
Examining and mending any and every condition that a widget might be in
When a set of cloud data is being fetched into a widget, the flow of the widget and its binning mechanism are reviewed to see how they respond.
Additionally, we offered additional customization options that were consistent with the widget theme functionality. We developed a few styles for the Table widget during the redesign that may be used to produce apps with a more unified appearance.
Based on multiple sprint planning we included 3 different theme style which are 🅐 Default 🅑 Sharp 🅒 Round to to let the developer freely choose a preset style and adjust them based on their App design need
Process
We then established a notion board to take note of all the widgets, their states, as well as any flaws before we began the reskinning process. The way of evaluating the widgets were mostly uses metrics and user stories. We eventually agreed on the context for each widget on the board following weekly discussions with QA and Git Discussions.
Since then, it has gotten a lot easier to put the missing balance between widgets and recommend other flow improvements to make it even better.
Why Reskinning was a good idea ?
Reskinning let us identify the root problem and potential small scale fix for them to see if they are being accepted by the users because it was hazardous to change the widget's flow in order to simplify the interaction and shortcomings they have
Our engineering team's workload with respect to reskinning was minimal. Due to the fact that engineering was spending the majority of their time on performance, we had very little bandwidth.
When creating an app, reskinning widgets gave us the idea for a better array of widgets and their strategy, and we learned about many major issues with the widgets we already had. For instance, it was difficult to provide a feature called Column Freeze for the Table widget.
Outcome and mpact
"Developers value performance over outlook." This is not always the case. They value both the appearance and the performance of their apps because they want them to work and look better. We began rolling out few reskinned widgets, which surprised them not only because they were getting more consistent widgets, but also because they could now build more beautiful apps right out of the box.
We've heard from companies that use Appsmith for internal apps that this change makes it even easier for them to compile apps built with Appsmith with their existing designs. This was a clear indication that our efforts were paying off, and we had resolved an issue that had previously been overlooked.
Table widget and Property
Table widget style variation
Table widget with other widgets in consistent style
Table widget with other widgets in consistent style
Scope - Column Freeze
The ability to make table widget columns persistent
Sticky columns make it easier for users to scroll horizontally across the table when it contains data from multiple columns.
Furthermore, it will eventually allow the app developer to fully control the data set on which they want their user to focus, such as IDs, Countries, and so on.
Unlike Google Sheets or Microsoft Excel, it appears that the challenge here is Appsmith's JS functionality. We had some difficulties incorporating the feature design because all of its controls are accessible from property as a mode of widget configuration that runs across multiple JS libraries.
Problem with table column
The main issue with the table column in the table widget is that if it is used to display a large set of data across the table, it becomes difficult to prioritise any specific data set on a column.
Because the data navigation method is set to scroll, no given column can display over a fixed position. We saw similar interactions in Excel and Google Slides, but due to functional differences and mechanisms, we planned for a simple way to incorporate the same feature.
That means we must design the widget property in such a way that it will
Include controls without disrupting the property's existing flow.
Simple to understand and use.
Match the existing JS library Appsmith has for the table widget.
Finding the Solution
After analysing the problem with PM and Engg team we started iterating some variation to see if any of the given option has the ability simplify
Prototype #1
This is the most common use case we have seen so far and the easiest to incorporate as a functionality bridge
The flow helps the user take control over the desired column to apply or allow freeze from the property and manage
its state from the property pane from column property options
Pros
JS ready, somewhat similer with existing table behaviour
Simple and initiative and common flow
Less confusion compared to other flow
Less engineering effort on implementation
Cons
No drag and drop control inlined with frozen column
Somewhat incomplete design since users cant move frozen columns straight from column list untill they unfreeze it
Fozen column stayed in their position after unfreeze
Unavailability of direct freeze control
Prototype #2
This flow helps the user enables the drag and drop experience to freeze or unfreeze any column directly from the property pane. Adjusting orientation or unfreezing the same. The best part is the table itself correlates to the property pane behaviour and thus it will eventually create
minimal confusion while performing the functionality
to enable user must need to toggle on column freeze functionality first
Pros
Drag and drop experience
Better correlation within table and property
Less confusion compared to other flow
Direct access to the functionality
Cons
JS support is questionable
Prototype #3
This flow is something we have experienced with the popular tools like MS Excel or Google sheet
where the Freeze has been delinked from the column property and will behave as an independent feature to control the Column freeze
by selecting the available option from a dropdown menu respective to the orientations
Pros
JS ready
Simple flow
Less confusion compared to other flow
Less engineering effort on implementation
Cons
Limited to the available freeze options
No communication between the column position and its state
Unfreeze column stayed in their position
MVP design
Context switching
Because Appsmith is a complex developer tool, it is possible for users to lose their workflow while working on multiple apps or in a team environment. The primary areas of builder can be classified as follows:
Canvas area - this is where developers drag and drop widgets to build the application.
Property pane - Control, combine, and adjust/add codes and functionality
Navigation panel - To navigate between databases, pages, apps, and so on.
Problem with context switching
Depending on the user category and building environment, users are struggling to switch over several parts of the builder and are compromising their focus on building apps. It is difficult for them to navigate to a page outside of the canvas simply because they need to combine a database or inject some code or js library.
Navigating between apps and discovering shared apps is a chore since it requires them to either open another window or close the builder. Which eventually becomes a hinderance when switching between tasks and remembering where they are on the builder.
Solution
To overcome this weakness on the product, I eventually try to start with a MVP Design without risking the uses pattern of the users and to collect more information on the problem
My main goal was to provide a path through which developers could navigate between multiple functionality without leaving the main canvas.
Outcome and takeaways
We have seen a significant decrease in the number of service desk complaints since the implementation of the new rebuild of the Table property and style tab. Furthermore, I've received positive feedback from developers about the simplified configuration, which has saved them a significant amount of time.
Some key takeaways from the projects are:
Create a strategic plan to launch an MVP. This helps deal with out-of-scope requests that could potentially derail the project and helps deliver a quality product in time.
User testing doesn't end after development. Design is a constant iteration of improving the experience for the end user. Always find ways to collect and listen to your user's feedback.
Involve engineering upfront. This helps to reduce any rework later on as an understanding of the technical limitations upfront will help to inform your design strategy.