We are working on a new Project to redesign the current User Interface (UI)

This is what I hear when someone says a version of the above statement-

1) “We were stupid enough to rush our first project following the management triangle and screwed the business over in the name of Digital Transformation. Now we are covering our own shit by spending more money and sugar coating the phrases around it.”

2) “We built 1000 features few years back, out of which only 15 are being used regularly. We are actually in deep shit in terms of coping with the maintenance cost of the rest. If we delete the rest (which we should), our bosses will bend us over and ride our arse off !”

3) “We are calling it a UI redesign but it really is a disguise to hire more developers to recover from the technical debt we ignored for the past few years.”

4) “We need to look busy as we are permanent middle managements. We need more meetings, whiteboards, sticky notes, sharpies and latest gadgets to save our worthless jobs.”

5) Finally, when a fellow “Consultant” says it, I hear – “We have managed to brainwash the client that they need a platform redesign of existing fully working application (not just UI), so we can place more expensive consultants (who will be paid half the amount as permanent employees btw) for the next few years. We can sell frameworks like Agile/Lean/DevOps and processes like SCRUM, xp, KANBAN (yes, someone actually wrote it to me once; god was feeling helpless). We can then convert them to one of the scaled agile frameworks.”

So I am not a fan of these characters, let’s move on. Although it was necessary to set the tone of this article to get things straight around fake “projects” which could have easily been a few months of lightweight but effective revamp work.

What’s wrong with UI re-designing?

Nothing. It’s always a good idea to present a fresher look to keep our application visually attractive than our competitors. Problem starts when we use it as an excuse to authorise a hefty budget for a spurious “Project” and not an improved “Product”.

It leaves a room for uncertainty and make our lives hell when we come across a surprise, which we were not expecting. Most “UI redesign” I have come across are basically the same application (with exact same features and specifications) from scratch with different technical stack aka a full platform implementation instead. You may have a better experience elsewhere. It just didn’t made sense at the beginning and didn’t created a sense of purpose. Instead it added high volume of unnecessary work in the backlog. Would love to hear a positive story, please share in the comments.

Top Root Causes

Product? What’s that?

It doesn’t always happen on purpose by the agents of “Change Management”. It happens due to a lack of knowledge in applying an approach which is based on empiricism and using a little less common sense. As long as we treat “development” as another standard project in the business, we will come across these issues. There are good agents, although less in number and are helpless as they won’t get the support from the culture.

Thankfully, a majority of thought leaders in our current world has made it very clear that we should focus on a product, dedicate a team towards it, iterate with empirical evidence and don’t work on anything which doesn’t have a purpose of providing value. May be the world is not ready for it, may be we need to let the world learn by it’s own mistake or maybe we can educate them faster instead of becoming their critic.

Here’s a Million, Burn it

Another root cause is having way too much to spend. No one care about a drop of water from an ocean or whatever analogy we use to describe it. That’s why the amount of waste is proportionally high when a company starts “scaling” their products. We don’t need scaling for products, we need descaling. We need iterations in burst mode so we can compare them and choose the one which actually provide some value and throw out the rest without feeling guilty about performing those small experiments.

In majority of companies, a predicted increase in revenue is measured as success.

 

“We need a 18% rise in the revenue next year as we managed to hit our last year’s target of 16.5%. To do that we will authorise a generous £2 Million on a re-design project proposed by the application development department for the existing application” – it is practically nothing in compared to that £100 Million+ profit they made last year.

Prediction is the worst kind of lie, it creates a sense of premature satisfaction.

Shareholders are happy as they have received more than their predicted cut last year and no improvement is required in anything as long as that number always increases according to “prediction”. Employees will be given bonus based on that as well, whether they have done their job or not.

Adding or Removing Features – Where to start?

Eat your own Dog Food – The What?!

If this concept is new to you – Dog food eating is a (well) known self scrutinising timeboxed event where you taste your own medicine and for a moment forget that you are part of the solution provider. The application we are building for someone, we use it in our own work and see how satisfied we are as the real user for a moment. In case the product is unrelated to our daily work, we pretend we are the user for the timebox.

Technically we should always be doing this without considering it as an event. Although I have seen only a handful of companies doing this and embracing the huge benefit around it. It’s not easy. You have to mimic that asshole who always wait for your mistake and resurface from the grave to screw your life around by changing your plan of action for another quarter (or worse, a year). Better be that critic yourself than giving a random opportunist take a ride.

Responding to change Over following a plan !

Identify the change needed before someone else do.

 

Summary of steps:

1. Plan a half day timebox for this session.
2. Make sure everyone on the team except the stakeholders join this. This is important – stakeholders will influence your opinion, so excluding them is a necessary step. You ARE the stakeholder in this session and you have to be brutally honest about it. If you don’t want to, don’t participate.
3. Create a template of activities to plan a basic layout, sort of like a session based exploratory testing protocol (get help from a QA member if necessary). Remember you are the end user of that feature – establish who that feature in intended to, doesn’t have to be of one kind.
4. Run the session and be a harsh critic of the platform, find anything that annoyed you.
5. Document everything you felt and found.
6. Plan few hours with stakeholders now, show them what you have found. Done.

 

From this point onwards, what a stakeholder decides will take effect, of course. But at least you have a much better understanding rather than reading a list of requirement which you always hated for being too vague.

If you are planning to achieve a sense of purpose start “dog food eating”, start analysing your own product, be your harshest critic and hire someone who makes sure the criticism doesn’t stop and call that role – Chief Nagging Officer.

Implement Analytics – as if you are prep’ing for a legal hearing

A Zombie feature don’t need to be loved, it needs to be shot in head on sight.

Analytics should be the simplest way to help a company on taking informed decision about “removing” a zombie feature. We don’t need analytics to add a new feature, addition is purely based on empiricism and can happen anytime. If we have implemented analytics (most does) but haven’t removed a feature based on the data, we are already doing it wrong. The deeper it is ingrained on our platform the better for greater insights. The purpose is simple – “We like to find out what part of the feature/platform is barely (never) used and delete the code to save maintenance cost”. It helps us in reducing technical debt and remove the stress of handling the legacy code.

It’s hard to throw out months of work knowing it is not being used. We can only blame ourselves for not doing enough research before implementation and make it right in the first place. Guess what, it’s never too late.

Adding or Removing Features – Why does it matter the most?

It’s in the name. We either add or we remove. It’s simpler, it’s almost black and white. While we are adding/removing a new/old feature we will always perform some background work on making it compatible with exciting features, redesign the UI in places, refactor the codebase or simply change the way it works or appear.

At the end, the value will be provided no matter what and it won’t become a worthless internal change with no real visibility of a new improvement. It can be a performance improvement which is not visible to naked eyes but an informative slide show can make up for it. There is always some value on everything, selecting the highest value is what matters.

There is a genuine reason a development team don’t get buy in from the stakeholders for removing technical debt. Often the team fail to provide an effective reason or simply fail to explain why it is important over providing a visible value.

New feature can equate to cost on one way or another, directly or indirectly, which is easier to articulate. When we remove a feature we have to heavily base our recommendations on analytics data explained above. It can still be equated to cost but still good luck with explaining why a working but unused feature was built in the first place. Some understands, some don’t. Be brave enough to raise concern but calm down if your job’s in question.

Conclusion

It comes back to the culture aspect, every time. The culture needs to translate these kind of failures as a learning. A zombie feature can use as much as the “resource” needed, as an actively used feature which makes them very expensive in long run. By resource, I mean real resources like storage, supporting work and maintenance costs which are a great form of waste. So focus on adding a new feature in demand or simply remove the one that nobody owns.. just don’t call it UI redesign.