Low-Code Development Platform

Lifion by ADP set its mission to create a one-stop HR solution for clients. The one-stop in their case is both the HR apps and a platform to build those apps. The platform's goal is to empower the HR practitioners to build custom apps they’ll need.

This is where a low-code development platform comes into the picture.

My role

My role as a UX Manager at Lifion is to lead the design team for the Lifion Developer Platform tools. I was tasked to support 28 different engineering teams. In order to manage the task,

I built the UX team from ground up and hired more full-stack designers with different specialized skills
Assigning team members to support multiple engineering teams with quarterly prioritized sheet to manage work load
Set up research processes inside the team to better understand the developers’ painpoints
Build the developer support portal learning platform

I worked with 3 other UX designers in my team to accomplished the task.

Key challenges

Lifion Developers (LDs) are saying the low-code idea is great but it’s really hard to use. They feel like they can do more if they aren’t limited to the platform.
Our low-code platform is based on the concept of having multiple apps, which are called “Designers”. But all these designers have different UI & UX, and it’s confusing for them to understand all the UX and processes.
A lot of LDs feel like the platform is a huge black hole. The more they learned, the more inconsistent learning curves they’d unpack, and there’s no standardized learning structure.
It is supposed to be a low-code platform, but it’s not really low-code in many areas.
LD teams are also developing differently, and the applications they’re developing are also having different UX. Lifion products don’t look like they come from the same company.

And this is how it looked like when I first joined Lifion.

Untangling the user issues

LD personas

To uncover problems inside a highly tangled and complex workflow, I started to work with my team members to understand user personas, and their journeys as Lifion Developers. We conducted 12 seperate 1:1 interviews with LD’s across a variety of teams and experience levels. We grouped our findings into three personas and four experience maps. But the overall user journey for a typical LD is very similar. They have to rely heavily on training materials, senior colleagues, and product wikis when they’re starting out and as they start to get familiar with the tool (after six months), they tend to help other LDs, file bugs to the platform and start to build their own tools.

Based on this data, we created 3 different LD personas based on their tenure, familiarity with the platform, and development process on the platform.

This is when I could have a glimpse into how we might be able to solve the five main problems stated before.

Lifion Developers (LDs) are saying the low-code idea is great but it’s really hard to use. They feel like they can do more if they are ’t limited to the platform.
- Targeted persona ≠ Current user
- UI trying to be HR friendly while it should have been developer-friendly
Our low-code platform is based on the concept of having multiple apps, which are called “Designers”. But all these designers have different UI & UX, and it’s confusing for them to understand all the UX and processes.
- Teams would use third-party code libraries to build their own designers, which creates inconsistent UX and UI across all Designers
A lot of LDs feel like the platform is a huge black hole. The more they learned, the more inconsistent learning curves they’d unpack, and there’s no standardized learning structure.
- Does’t have consistent application architecture and using wrong UI component for the wrong interaction
- Need a developer community for support
It is supposed to be a low-code platform, but it’s not really low-code in many areas.
- Need more understanding on where low-code industry is going
LD teams are also developing differently, and the applications they’re developing are also having different UX. Lifion products don’t look like they come from the same company.
- Creating a way to allow LDs to build off approved patterns

Understanding the industry

We clearly saw that the product users and product directions are ’t matching with the personas project. To come up with a product design solution, I worked with my team members to

Understand other players in the market
What’s working, and what’s not working on these platforms
What’s important to developers when shopping for low-code platform and how do they make purchasing decisions
Trends in the low-code market
Mapping what’s important to users

We looked at reports from Forrester, Gartner, and Customers' Choice. We found that 84% of businesses have chosen low-code because it can save IT resources, speed up the time it takes to create digital assets, and involve the business in creating digital assets.

Regarding capabilities criteria, we also found more product areas we could put more focus on.

General experience - How pleasant and intuitive is the system to interact with and use
Integration - Ease and availability of integrating 3rd party software and data
Product Lifecycle Support - Support versioning with platform updates so that client apps don’t break with software updates
Management - Easily manage data, content, integrations
Implementation - Process of building a new features or application, rapidly. Ability for client to customize applications based on specialized UX, dev, and business needs
Development - Committing builds to a server
Supports Complexity - Enables design and build for large, enterprise projects with more custom (as opposed to out-of-the-box) features
Learning & Community - Developers are empowered and capable of learning the tools with minimal frustration or oversight

We were able to provide these findings which allowed the senior leadership team to make decisions on who they want to target in the market.

Comet Design System

The engineering teams were using numerous third-party design systems, which was causing UI and UX issues for the LDs. To resolve that, I led the team to create our own design system and guidelines to support the engineering team. I based it on atomic design system architecture to create different levels of components. I set up guidelines on when to add a new component and when to reuse the existing components.

To make the communication with engineering teams smoother, we built the design system website ourselves and turned it into a hub for engineering and product to learn about our design language and research data.

I led the team to take the next step in the design process by even writing our own CSS design tokens ourselves. This made our undestanding of frontend development a lot better and helped with the communication with the engineering team.

After releasing the design system, supporting the engineering team, and starting to redesign our products, we were able to revamp the UI/UX of the development platform.

Lifion Developer Portal

To have a one-stop shop for the training materials, and new feature release, I worked with the product leaders to create a Lifion Developer Portal on Confluence. We looked at different developer support sites from top companies to understand what are the best practices and how they manage to get their developer community to be engaged.

Team management

It was a huge challenge to have only four designers, including myself, to support 28 different engineering teams. Timeline was always tight, and resources were never enough. This is when I used company OKRs to understand priorities, quarterly plans on which teams to support, and made my team to prepare for their quarterly work ahead of time to make sure my team provide partner success and product success.

Conclusion

Things we noticed

The number of blocks added per minute to create block structure (editing properties not included) jumped from 26 to 45
Total time needed to finish an end-to-end development reduced from 4.5 sprints to 3 sprints
Total time required to bind data from database to the UI reduced from 35 mins to 8 mins
Learning curves for new LDs has smoothen out over time. This resulted in total time needed for LDs to be fully independent reduced from more than 8 months to 4.5 months

Reasons and features that contributed

A feature that enables LDs to add blocks using only the keyboard and allowing ML suggestions to be at the top
File tree and multi-designer tabs features allow LDs to stay focus on the development even when there are multiple projects in the sprint
Dual-panel modal that lists input and output from UI and fields from database makes it easier and clearer for LDs
Building out the developer portal and the community, and integrating new features alerts inside the designer played a huge role in this