Experience Report: Front end migrations

Introduction

By its nature, UX needs to take into account the wider context rather than solely the piece under discussion. A website should provide a coherent experience and adding features that jar with the remainder of a page will be unlikely to drive metrics in the direction we wish. This can result in UX taking a long time, with delivery crawling to a halt.

Experience Report

One project I joined was a migration project. The goal was to migrate off the old backend and, at the same time, update the front end. At the time, these were joined in a horrible spaghetti system, so moving made sense. The front end was being designed page-by-page, picking out all the features on the existing site and redesigning them.

This isn’t an optimal way of doing things. If the front end is changing page-by-page, then the full functionality is being replicated (even the stuff that’s not great for users) and there still needs to be a full user journey in place. So we end up with a system where nobody gets migrated until there’s a full new site in place.

Can you see any risk here?
Can you see any risk here?

Ultimately, this project got parked and instead the decision was taken to move onto another project’s infrastructure, achieve feature parity and then move beyond that. This is still risky but less so; the time to releasing something is lower given that the infrastructure exists.

So how would this risk be reduced?

Firstly, this project started with a feature list that was the minimum set for all users. But then within that we identified subsets that would appeal to other target groups. For example, we don’t need all the features for newly registered users. So perhaps some users can be migrated earlier, giving vital feedback and establishing the habit of releasing features.

Secondly, the UX team wouldn’t attempt a discovery process for every feature. The business outcome is to get off the old system without losing revenue. So let’s simply design the non-core features and reserve discovery for the vital pieces or for the second iteration.

This was a change for the UX team. It’s uncomfortable; the website won’t be immaculate and at times some aspects not be as great as they could be. We try to minimise this, but it’s occasionally inevitable.

Brief Reflection

Is this optimal? No.

Is this a better place to be given our current situation? Yes.

Are we learning? Yes.

So how could we do this better? Ultimately, I would love to see us to move to a continuous improvement model where migrations aren’t necessary as the back-end is updated 

So this project is arguably not classic agile nor lean. But it is moving toward that goal and we’re learning. I’m interested to hear other experience reports from website migrations. How have you managed these using agile / lean principles? What pitfalls have you had to overcome? And where were your biggest compromises?

Advertisements

Author: Stuff Rich Writes

Cyclist and Product Manager. I blog about both.

One thought on “Experience Report: Front end migrations”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s