How to Solve a Problem on the Web

Here is a scenario: Someone suggests what seems to them to be a more efficient way to do something that really doesn't need to be changed, but appears as if it should be changed because they have inconvenienced themselves due to ignorance.

I remember sometime during the dawn of the web, when an email administrator (back then a person who just "took care of the emails") said

"Hey man, don't use background images, OK?"

We listened because they were the one testing and sending the emails, and as bad as we wanted to put background images in the email there was a big chance that someone out there was using 1 of a gazillion different email systems (yahoo, gmail, lotus notes, etc) and not all of them could see the background images.

This is something you accept. You don't question it, because really, it doesn't need to be questioned.

Every company has their own way of doing things when it comes to everything, and if your CEO says make your internal business newsletter published via intranet, then that is what you do.

If someone wants to change it - the way it is published and distributed for example - then what?

Well then, I suggest really solving the problem - and that means getting together all parties involved, identifying the problem, and then coming up with a way to solve it.

More than too many times a designer will test and reconfigure in their own environment which does not come close to the live environment that the content will actually be published on.

What happens is the designer will work more hours on a problem that doesn't need to be solved.

But lets say you do want to solve the problem. You'll have to get all the stakeholders in one room, agree on what the problem is, make a list of possible solutions, then follow up on each of them.

Often times there are too many stakeholders attached to fixing a problem that has not been pre-scheduled on their quarter-by-quarter to-do list, so fixing what might be considered a small problem can become a large problem rather quickly.

To stay on top of most any issue, it helps to know the life cycle of each and every project in your department. From there you can address how to change something - but only if the original process is documented first and only if the changes provide a clear benefit from the way you are doing things now.