It is dangerous to give control over an idea or already existing product to non-designers or amateurs. Despite their disbelief and even with best intentions in mind, they lack the skill and knowledge to design features and changes.
I have noticed this on so many projects. Whether it was because of programmers, project managers or global leaders pretending to be designers, or sloppy and amateurish work – even mine at times – the project always suffered. Sometimes just slightly and sometimes so much it became a disaster that needed to be taken off and hidden from sight of all users.
Clean slate is an opportunity
In one of my previous posts I addressed minimal viable product. It is topic I will touch on.
Even though it should be standard to simplify products over time, it is not realistic. There comes a point when you have to take what you learned from old, overcrowded version with no place to add new updates and simply start over. A clean slate – in a sense – where you can use all the accomplishments and positive feedback you gained, incorporate solutions to negative feedback and most importantly, don't repeat the same mistakes.
Every product goes through this stage once in a while. It usually takes years to arrive at this moment. As you are working from scratch to rebuild the old thing into a new thing, you must be ready to support the old solution as you are building a better one until it is ready to see the light of day.
This is something many people tend to miss. It requires implementing a change and that comes with possibility of failure. Some are scared, some just think using legacy product and cramming as many features in as possible, is a way to go. This thinking prevents innovation and improvement.
Last time I was redesigning a product which was literally flooded with mistakes and bad decisions, I had the luxury of working in a team of people who understood the need for minimalistic design. And even though we had full control over the direction, there were “the others” watching over us, waiting to strike.
We made minimizing the tool and reducing the clutter our job. We wanted to implement only useful features and leave behind everything that was there only to stand in the way. While we were reducing volume of the tool by more than a half, we made it actually joyful to use and capable of performing every task it was expected to. The others from outside our team wanted to add features that would solve no problem and bring absolutely no benefit.
We endured and our tool received positive feedback. It was simple, yet powerful and it was fun to use. But we eventually had to end maintaining it. We took new projects and this one was handed to the next team, a team without UX designer.
New release with no problem to solve
When we lost control over the tool we tried to at least remain as consultants to be able to shape the decisions and direction of the new updates. It was good call considering the first design of a new version made no sense.
There was a clear problem to solve – a fact that surprised me. Their strategy was clear and the benefit of requested solution was reasonable and worthwhile. Yet, the design did not solve the problem. Instead it went ahead creating more problems. The working parts that were good were to be redesigned in a horrific way while the bugs plaguing users tasks were not supposed to be fixed.
The new features that were to be added were not only useless but already tested and found out to be useless in the old generation of the tool. The problem which was the sole reason for the new release was never addressed in the design of the release.
Despite our best efforts to explain this – suggesting pixel perfect mockups of an actual solution that was always part of the overall strategy of the tool and therefore prepared to be implemented – the new nothing-solving design was chosen.
Instead of releasing a version that would comply with the strategy for the tool and process, would take 2 days to develop and would actually improve the tool, the new leaders of the project decided to spend 2 months of development to make the tool worse – keep the same bugs, implement useless features, ignore requested features and destroy already well working features.
And so the tool is pain to use now. It goes back in the direction of the old legacy tool by introducing useless features, maintaining all the bugs, worsening what works.
The disaster with no strategy
I already addressed technical experts messing with design, but lot of times it is not developers or tech leads, it can also be managers and leaders.
The worst thing that can happen to a badly designed product is being taken down, swept under a rug and then be resurrected with the same problems and mind-set expecting different outcome.
Another tool I had the luck to come across was one that needed to be done immediately, or yesterday, if you wish. We spent Friday evening and night in the office because of the great importance of it.
The first red flag – among many that emerged – was the claim that it is important because of big strategy that was to be implemented across the company and this tool was essential to it. Ok, so why was it not requested beforehand and actually done properly instead of rushing it in a day. It spoke a lot about the so called strategy.
Another red flags were visible right as we looked at the premise of the tool. The outcome was not clear, the users were no clear, the numbers we were supposed to use in the tool were flawed and the best part of this was the communication with clients.
I realized an issue in the current process, issue that constantly needed to have workarounds. The new tool was of course not solving this issue but building on top of it. So I asked the clients about it, told them about it and the of workarounds, suggested different approach based on research – although limited due to time restrictions – and the reply I was given was a rhetorical question: “Does the current process allow that flawed course of action? Yes. So we will use it.”
I was astonished. Of course current process allows a flaw in the current process. Its the most ridiculous thing I have heard. If you asked that every time something needed to be fixed, nothing would ever got fixed. It just ensured me that there was no intention to improve anything, there was no strategy, no plan.
Tool was later found lacking in certain areas:
- It was visible to users for whom it was created and approved – that was evaluated as a mistake as those users were not supposed to see it.
- The incorrect numbers which were communicated to the clients and approved anyhow were found to be incorrect.
- The tool was criticised by the clients for being rushed and done too quickly by us and therefore very minimalistic and using incorrect numbers.
For these reasons it was removed, hidden, destroyed and never spoke of again. Until month later when it needed to be done in 3 days as it was part of big strategy across the company. The users who were supposed to use this new tool in the mere 3 days were not aware of anything happening, the features and numbers were kind of a guess and the process “allowed for flaws”.
Conclusion
It is important to use opportunity to minimize product, start over and not be afraid of it. Legacy software is usually riddled with things that are not supposed to be there anymore even if they once served a purpose.
When designing new version, do not add features that are not needed. Focus on solutions to real problems. Your tool will remain good and will live longer in long run.
Strategy and design are tied together. If one is not present, the other will not save it. Having perfect tool with bullshit goal is going to end up a failure. Expecting different outcomes with same inputs will also go sideways. For that reason it is important to work on foundation before moving to walls and roof.
No comments:
Post a Comment