Design at Scale 2021- Lessons Learned from a 4-Year Product Replatforming Journey (Malini Rao)

—> I’m here to talk about a four-year product replatforming journey

 

—> Design product experience for UKG, with a focus on small to mid-size enterprise

 

—> At most points, we have worked on old and legacy application UX
  • It’s hard to make changes to systems as it’s risk ridden, and major undertaking
—> In last several years, there has been big movement to move to replatforming legacy systems

 

—> Any major shift is multi-tiered and org will invest at different levels
  • 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

—> Replatforming is a large effort, and no two replatforming journeys are the same
  • No single formula works every time

 

 

—> I’ll share the story of UKG’s replatforming, what they did and how they pivoted, to give you more confidence in doing this process
  • Share four learnings from experience, and five takeaways
—> I’m not here to stand as expert in replatforming and here to walk you through what needed to be done in evolving factors in journey and see what could have been done better and factors in own journey

 

—> Let’s begin with context:
  • 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

 

—> Once you take on replatforming the goals just pile on

 

—> We anted to covert an existing legacy application into a device agnostic experience, but business goals kept coming and arrived as curveballs, so we needed to adapt

 

—> Began with technology focus of what it meant to be on a cloud platform

 

—> Ongoing business goals don’t stop, even with re-platforming
  • We needed to cover feature gaps and needed to produce new features while updating the platform
—> We needed to simplify experience for employees and managers to allow self-service
—> We had a two-year time limit to get replatforming done, and several strategies in converting legacy applications
  • 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
—> We began to come up with mega-patterns to share with development partners to make application changes
—> We then rolled out UI within Agile environment and realized they needed to chase adoption
  • As we struggled with adoption, we also needed to consider persona for the “power users” of the systems
—> In the process of creating responsive one-size fits-all strategies, we neglected power users who spent the most time on applications

 

—> When needed to flip the switch from one system to another, we needed to focus on customer retention in order to make transition

 

—> UKG’s cloud replatforming, reflected the journey from screen to application level to organization level, up to considering the eco-system level from business/customer side

 

—> We also need to talk about how UX designer traveled from different scales, from product to feature level

 

—> UX team travels these scales as well, during the replatforming journey
  • 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
—> Journey doesn’t have set off switch
  • 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

 

 

—> Re-platforming is transformative for teams and the organization and the whole, not just for the process

 

 

—> With that in mind let’s look at four lessons

 

—> First, there is no solid way you can control course of replatforming project

 

—> This is not just about UX, but technology, business/market drivers, and how you as UX team can determine extent to which journey can be influenced

 

—> Success on replatforming will depend on ability to take risks and adjust as based on needs  as they arise

 

—> Next lesson is the curse of hyper-focus or fixating on a particular aspect of the project

 

—> This is especially important during replatforming especially when the initial goal is so vague, that it becomes inevitable to fixate on a certain piece, and lose the overall vision

 

—> Hyper-focus can happen at any time during a journey

 

—> It can happen with technical strategy
  •     We forgot about cost of other personas for customers
—> It can happen during roadmap planning
  • 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
—> It can happen during execution
  • 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

—> However you slice and dice mission, make sure strategy is enabling, not impeding, the customer
  • 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

 

—> W need to think of product consumability of ease of adoption and time to value

 

—> SaaS is subscription based, so we need to get familiar with key SaaS metrics like retention metrics, and adoption metrics like “Time-to-Value”

 

—> We are not just designing for a delightful user experience, but a focus on changing familiar habits, and designing a roll-out alongside the product experience

 

—> Articulate rationale to understand the product, and exploring the feature tours and trial toggles

 

—> Remember that critical change agent personas, who determine adoption and success of product
  • Don’t ignore these actors

 

—> Also need to plan for change internally.
  •     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

 

—> Mentally, need to prepare to encounter resistance to the replatforming, as you will encounter it during the process
  • Customers might not buy into reason for replatforming, as they may have learned legacy systems and associated workarounds

 

—> There is also overhead for customers and loss of efficiency for power users that others depend on
  • Naturally there is angst and resistance to do this
—> You need to distinguish real pain, from initial resistance. Cannot simply rely loud voices from particular customers, but instead find ways  to get feedback at scale
  • 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
—> Whatever happens, acknowledge there will be some initial resistance
  • Acknowledge the risk of forcing customers to adjust more than once, and people preferring different products
—> If you are an organization leader, keep a pulse on team morale for replatforming, since it’s so painstaking and complex
  • 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

 

—>  Change is hard, so brace for initial resistance, but don’t stop listening to your customers

 

—> Always work to distinguish actual paint points from resistance itself

So here are our five chief takeaways:
—> Don’t lose sight of whole experience, as UX designers are interested in all users
—> Be strategic in enabling key change agents
—> Replatforming is long and fraught with many hard decisions. While the UX team may or may not control or influence, can work to keep customer lens on
—> Do not forget on team morale throughout the replatforming, the same focus on customers
  • Teams can feel they have been enriched by the replatforming, but can also feel burned out and deflated as well

 

Q&A

 

  1. Are usability/ease of use not directly correlated with adoptability/speed to value?
—> Metric doesn’t cover it fully, as there are other aspects that need to be considered such as the timing, and the change introduced

 

—> Other changes need to be considered in addition to ease of use