Photo by Slava Bowman on Unsplash

I had a bit of a digital epiphany. I was tasked with working on what was perhaps one of the most difficult legacy coded projects before. To keep things short it used a popular Php framework without actually using it.

Long story — lets not talk about it

The job was very simple — theoretically — to modify a simple formula. This would have been a piece of cake had the application been coded properly.

Anyway the details are quite morbid, working on the project became a yo yo battle between development and testing. The formula had been applied but results weren’t being displayed as expected. And the fact that the site had logic spawn all over the place i.e logic in the models, controllers and views and even helper files. It was a complete disregard for MVC, OOP or any basic structure of development.

But enough of how bad it was, point being is that since there wasn’t much of a structure to the code — I found myself actually disregarding all facets of structural programming in the attempt to completely finish off the project. The result was that it overshot the deadline by almost a month, and we found ourselves running around in circles. Modifying the code in one place would break something elsewhere and so forth. At this point it became more of getting the project out the door than to do a good job of development.

We were pretty much close to a dead end with a report, that no matter how many variations I’d make of it, it never seemed right to the testing team. At hat point our lead Q/A in charge told us to:

Think from the users point of view

I had pretty much heard it a number of times before but at that point it struck me in a way that it actually made colossal sense. We had been looking at the report from all possibilities, except as how an end user would — which pretty much includes 100% of the entire user base.

Point being is that, great programs that we use aren’t based solely on how well or bad they’ve been built but on how useful they are to the end user. As programmers we could pretty much get away with command line interfaces but the bulk of our user base defines the usability of a project. The legacy application we worked upon was a nightmare i development strategies but from a users perspective, it did the job quite effectively. Once we started looking at it from the end users perspective, we suddenly understood how it needed to function — thus overcoming the apparent lack of any concrete documentation. Once you know what the end product should work like — the rest becomes easier.

“Cat: Where are you going?
Alice: Which way should I go?
Cat: That depends on where you are going.
Alice: I don’t know.
Cat: Then it doesn’t matter which way you go.”

― Lewis Carroll, Alice in Wonderland

Its easy to be judgmental and look at the end user as some what computer illiterate and lay the blame on them for not being able to properly use an application.

Don’t be this guy…

But at the end of the day, the end user defines how the end product would be used.

Reports that show only what the user needs to know, rather than be inundated with excessive or unrelated information are easier to digest by users. Simpler smarter forms that give users some leeway — all that translates to repeat users which in turn translates to a very usable product. And usable products bring in money at the end of the day.

Empathize with the user, we’ll be done with a project once its functionally ready and all tests run clear but our customer is going to be stuck with it for a long time. I once recall back in college having made a survey for a class project. The survey questionnaire was 5 pages long and had around 15 questions. Why was it 5 pages long you may ask — because each page had just three open ended questions and a huge box to fill in the answer. Out of 20 users only one actually took the time out to answer all the questions and that too was the Accounts teacher. I learnt the hard way back then why surveys are almost always multiple choice or boolean answer based. Sheepishly we redid the survey, same number of questions only this time we gave options of possible answers. Needless to say we were done within an hour of collecting responses.

In more ways than one…

Point made — with building any application, no matter how complex or simple — the ultimate perspective is that of who ever’s going to be using it day after day. This gives another dimension to the saying that the ‘customer is king’.

If your customer can’t use it, its not ready, its not done. Keep that in mind and you’ll see what makes an awesome product.

Source link—-138adf9c44c—4


Please enter your comment!
Please enter your name here