Design at Scale 2021- Lessons Learned from a 4-Year Product Replatforming Journey (Malini Rao)
-
It’s hard to make changes to systems as it’s risk ridden, and major undertaking
-
Rehosting: Moving the application to cloud service
-
Rearchitecture: Tweaking back-end applications to function better in cloud
-
Replatforming takes it further changing application components so that app thrives in cloud
-
No single formula works every time
-
Share four learnings from experience, and five takeaways
-
UKG is flagship workforce management product suite, focused on small-mid-size buisness
-
UKG is involved with everything from attracting talent, to the entire hire to retire employee cycle
-
We needed to cover feature gaps and needed to produce new features while updating the platform
-
Took high frequency use cases for each module, and tried to hit the most critical ones
-
Did visual refresh on old material first to minimize difference between new and old
-
As we struggled with adoption, we also needed to consider persona for the “power users” of the systems
-
UX team embedded in various engineering teams and responding to ask from technology focus, at most working on surface-level visual refreshes
-
Then moved to service/support and could take consistency across all product suite
-
Could later take on more driving role, as they saw impact of service on customer and business ecosystem
-
Our prior parent companies merged, and now focusing on what new experience brand will be for UKG, since prior parent companies merged
—> Path traversing design scale is not a linear one, but circular, and we switch from different scales in various ways
—> With that in mind let’s look at four lessons
—> Success on replatforming will depend on ability to take risks and adjust as based on needs as they arise
-
We forgot about cost of other personas for customers
-
Chunking of features, and focusing on factory model, along with distributed UX team didn’t enable team to have sophisticated desktop breakpoints
-
Power users were left out as a result
-
Example had central backbone feature of employee record in product, and 93 widgets associated with employee record
-
Conversion of widget after widget, but risk that sum of parts is not whole
-
Needed to recall how the feature was used, as some of that was result, and it resulted in customer angst
-
-
Otherwise expect costly resets
—> Next, just as it is important to design for change management as it it is to have product experience strategy, especially for a SaaS offering
-
Don’t ignore these actors
-
As we rolled out the new experience, we saw that support calls went up when changes happened, and agents were telling customers to stick with old UI, which sent a mixed message
-
We needed a way to align rationale across cross-functional teams
—> Change management should not be an afterthought. Consider customer perspective and internal buy-in for smooth rollout
-
Customers might not buy into reason for replatforming, as they may have learned legacy systems and associated workarounds
-
Naturally there is angst and resistance to do this
-
We had an in-product feedback framework that was useful to get more people involved, and had standardized scale to calculate and compare how the product was doing in different areas
-
We could correlate feedback to specific areas of the replatforming
-
Acknowledge the risk of forcing customers to adjust more than once, and people preferring different products
-
Teams can feel defeated and deflated with the resistance to the replatforming process
-
Recognize you are impacting customers lives deeply, and that replatforming is helping customers’s
-
Managing transition with empathy will help
-
-
Teams can feel they have been enriched by the replatforming, but can also feel burned out and deflated as well
Q&A
- Are usability/ease of use not directly correlated with adoptability/speed to value?