Sponsored
We spoke with Christopher Fahey, head of platform UX at Lifion by ADP. He explains the vision driving this next generation of HR technology, and discusses the capabilities it offers to both developers and business end users.
Next Gen is a pretty wide-ranging platform, handling a number of different tasks for a number of different user sets. How do you approach solving that kind of design problem?
When you ask about different kinds of user sets, the first thing that comes into my mind is the left-brain, right-brain thinking of our team.
One part of the team is building the HCM product, and the other one is creating the tools that enable building the HCM product. It’s like building a car: Whether you’re building an electric car or a regular car, you still have to solve the same problems. You need comfortable seats, you need brakes, you need the controls to be in the right places.
In this Q&A, @ADP Next Gen's head of platform UX @ChrisFahey talks about the next generation of HCM technology and how it will impact both developers and business users. #HR #HRTech Click To TweetBut if it’s an electric car, there are a lot of other problems that need to be solved. There’s new UI capabilities, for instance. You have to manage how much energy you have, and monitor how many miles can you go on that energy. You have to decide where the battery goes. And then you have to consider how this brand-new technology is going to change the manufacturing process.
The Next Gen team is actually comprised not just of UX people, but people across the board who are building the platform and building the product.
You’ve got a platform that serves different kinds of people, who have different levels of knowledge and are doing different kinds of things. What’s the strategy for serving all of these different needs with a common technology?
One part of our team is building the HCM product, and the other part is creating the tools that enable building the HCM product.
Next Gen HCM is based on ADP’s Lifion Development platform, which has a whole host of technological innovations underneath it—things like a graph database and hosting in the cloud. A key component is our low-code development environment for how we build apps, and just the fact that we’re building on a platform in the first place is important.
This all means two things. One is it’s really fast to get a product from concept into the actual user’s hands. Second, it means that the product can be consistent with every other product that’s built on the platform. Rather than giving developers a completely open-ended framework for building user experiences, we give them a harmonious set of compatible “Legos”.
When you build different things out of the same set of Legos, you get a tremendous consistency. You can re-use patterns and underlying technologies to make the user experiences consistent and to update them seamlessly over time. That’s one of the overall strategies to help users work more efficiently.
I think of our users as being in two basic categories: People who build apps and people who use apps. We make sure the experience is consistent for our end users—meaning employees and managers and practitioners—by giving our developer users consistent, powerful, flexible and scalable tools. That makes sure that the user experience is consistent and scalable and can evolve over time.
Are the people using the low-code tools customers, or are they people within ADP’s development team?
They’re both.
Low-code development is a huge movement in software, but it’s still in the early days. When developing a product, there are so many design decisions to be made—and by design, I mean more than UI design. I mean product design and software design. The reality is that, essentially, most of the important product decisions are business decisions.
The biggest difference between a great product and another product isn’t how well it was programmed, or even how attractive the visual design is. It’s the ideas that went into it. What problem does it solve? What business processes does it support? What data does it use? What user experience does it deliver? We want to empower our developers to make these kinds of meaningful decisions and not sweat over things like “did I miss a parenthesis in my code?” or “does this button match the other buttons in my app?”
If you’re already a seasoned programmer or you have a computer science degree, great—this just makes some things go faster. If you’re not a seasoned programmer, but you know something about how software is supposed to work to benefit users and customers, our vision is that you can use the platform to make software.
What’s the impact of low-code capabilities on customers? Does it allow them to build their own applications, in their own ways, with their own capabilities?
I’ll use a metaphor here. When Apple released the iPhone, they came out with hardware—the iPhone—and the operating system—iOS. They built a suite of apps to go with the phone, pre-installed—mail and weather and stocks and messages and maps. All of those apps were built into the phone.
They created these apps with an Apple development tool called Xcode. When Apple opened the App Store, they allowed anyone who wanted to download Xcode and use it to build their own apps, put them in their App Store and sell them.
This is 100% our vision, too. Right now, we’re in the stage of using our development tool ourselves, our version of Xcode, to create the foundational suite of HCM apps for our “HR operating system.” Our apps aren’t weather and email, but instead are performance reviews, talent management, payroll, org charts—all of the necessary pieces of a global enterprise HCM ecosystem. We’re building them using our tools, but we’ll be releasing those tools to a broader developer community, starting with third-party developers and clients.
There’s another piece to this, as well. When a client comes on board, the low-code tool lets us work with them to customize our product quickly. We’re trying to build products that work out of the box for as many customers as possible, but inevitability some clients need something to be specialized for them. This approach gives us the option to build new features and capabilities, quickly. Eventually we’ll allow our client IT teams to use our development platform to build apps directly for their internal operations.
Do you think that’s going to happen a lot?
I’m not entirely sure, but think about the Salesforce model. They’re not low-code, but they do have a very robust developer ecosystem. And they are likely going to offer more and more low-code solutions over time. And it’s been proven out in other industries—not in our industry, yet, but we believe we can innovate there and create that audience.
You work with a design system called Beacon. What is it, and how does it fit into your overall strategy?
It’s a huge part of the overall strategy. If there’s one big trend in the world of user experience design and product design, it’s design systems. The idea is that in a large organization with lots of designers, or in a development community with lots of developers, you want to make sure that there’s consistency and flexibility and speed in creating software. A lot of companies—from Google to Salesforce and even Microsoft and Apple—have been taking this approach for a long time: They create guidelines and standards and even UI components—buttons and menus and other standard UI elements—that designers use like Legos to build interfaces.
About 99% of the time, design systems are still implemented by developers wrangling code. Designers still need to work with skilled programmers and developers to make their interfaces a reality. The vision for design systems is to reduce the number of mundane decisions that designers need to make every day about stylistic details, about aesthetics. We don’t want UX designers to be choosing which font should be used for this product or that product, or which color should be used for the button at the bottom of a form. You can’t change the color of the ADP logo, for example, and you can’t change the color of the buttons on our pages. We want people to follow certain design guidelines.
What’s different about Beacon is that it’s built into the platform. So it leapfrogs all the other design systems out there where there are standards—much like a style guide for a brand—that are manifested in a bunch of code, meaning developers are still needed to implement web pages or mobile screens. By having Beacon built into the platform, we enable low-code developers to build products that are consistent with the platform.
For instance, there’s a UI design tool built into the system with a drag-and-drop interface. I want a headline here. I want a button there. I want two columns here. I want a table here with the following fields in it. It’s all just dragging and dropping and pull-down menus and Bam, it creates a screen that’s consistent with the rest of the product.
Because it’s built into the platform, there’s no gap between the developer and the designer. They can be the same person, using the same tools to create that experience.
So is it hiding the plumbing, or is it just pre-packaging things?
The plumbing is all there. For example, if I, as a designer, want to have a table on the screen, we have a table component. You drag that table onto the canvas and then you just wire up the columns to fields in a database through drop-down menus. Then you’ve got a table full of data on the screen. It’s very, very fast to do that, especially if those tables already exist in the HCM system of record. I don’t need to have multiple systems of record to draw on when creating applications. It’s all part of the same ecosystem.
ADP Next Gen HCM is designed for how teams work – helping you break down silos, improve engagement and performance, and create a culture of connection. Learn more at flowofwork.adp.com. ADP Next Gen is a sponsor of the HCM Technology Report.
Sign up for our newsletter here.
Image: iStock
