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

Making cycle lanes mandatory

The future...
The future…

Trolling

Boris Johnson stated yesterday that “it would be shame if cyclists didn’t use the superhighway” and that they “would be crazy not to use [it]”. This has been pulled into a wider question about whether cyclists would be made to use the new cycle superhighways, one of which is being built on Embankment. (link, around 18m in) Now, this was in response to a question from Nick Ferrari, who appears to think of himself as a controversial interviewer, rather than simply a troll with a radio show. His disdain for people on bikes is previously documented so Boris may well have been fending off an idiot question. There’s no good way of answering this and Ferrari isn’t going to give the stage to an answer he doesn’t like. Boris Johnson on LBC: 'like Billy Bunter on steroids'.

Feeding the Troll

But let’s humour Ferrari. After all, this question will likely now be asked by people who are capable of thinking but are temporarily choosing not to. Firstly, we should clarify what a mandatory cycle lanes is. These are mandatory for motor vehicles to stay out of, not for bicycles to use. When simply painted, they are useful for cars to park on and for spotting drivers who don’t know the law. This clearly presents an issue with legislating for mandatory use. There are some segregated lanes in London already (see below). These are narrow and only wide enough for single file cyclists. Given the number of cyclists in rush hour London, this is clearly inadequate and the road will be more convenient.

Existing segregation in London (c) google maps
Existing segregation in London (c) google maps

And here’s the point. If the new superhighways are up to the job with convenient entry and exit points, they’ll get used. If they’re too narrow and it’s awkward to get off the highway, people will use the road. Use of the superhighway therefore indicates the present utility of it. If it’s full of leaves and flooded it will be safer to use the road and it would be ludicrous to legislate against this. The simple fact is that without provision on access roads, the highways won’t be suitable for every rider at every point in their present state. These highways are good (not great) provision, but we’ve not removed motor traffic from rat runs, or put segregated lanes on smaller roads. To suggest that these sections of road should be mandatory is premature and simply a sop to the uninformed. Boris would be better spending his time putting across some sense, or simply ignoring the idiots.

An Invite

To the point of comprehensive infrastructure, I’d like to help inform my local MP, James Berry, of bike riding conditions by having him join me on a commute to work. I travel past Westminster, so this would be highly convenient to drop him off. This is a great chance to see what works, what doesn’t and what feels safe or otherwise. I believe one of his colleagues has a place nearby that will have a shower and a secure place to leave his bike.

Dave's gaff
Dave’s gaff