How this came about?

As mentioned on the article about the audience-facing frontend, this was the second phase of the entire TPI project. Even though we wanted to follow where the online events industry was headed, towards a self-serving platform, we also realised from daily usage, that the clients still preferred us handling the backend for them.

At that point, there was only 2 of us from within the company that knew how to set it up, leaving aside the devs. There was an urgent need to make it friendly enough to let other members of the team get familiar with the platform. Talk about spreading your risk.

Months of observance, gives you insights into the target users you are building it for.

Since the rest of the team were well-versed with setting up and operating major audio/video equipments, there was a way at which they went about doing things. Their familiarity to follow certain sequences during setup/teardown, the equipment they use on a daily, all of which gave some sense of what they would find easy to use.

With these things in check, I went off to build the first few sketches for the dashboard. It was easy to start with the main dashboard as that is where much of the data resides. We could easily punch in some random values, and start working on the layouts.

Research & Analysis.

Being operators of huge A/V components, it became apparent the staff were used to big buttons, and an all-showing dashboard. Best if any particular feature or setting was not too deep in the hierarchy of the site. They seemed to use their cookie crumbs quite diligently while navigating deeper into the system.

There also was a need for a separate UI that only handled controls for any Live events. Imagine being in the cockpit of a fighter jet. To only be focused on what concerns you for that one Live event. Not to be distracted or be able to steer too far away from where the action was.

Innovation is not always necessary in every aspect of the Product Dev cycle.

When designing dashboards, more often than not, it is much safer to go with familiar components and inputs. Trying to innovate too much, will only slow down the action that the user is trying to carry out. Speed here, trumps fancy animations and innovative UI behaviours.

For this project, it took me close to 1.5 months to layout every single screen there was. After laying them out in order of the workflow, I looked at the input controls. At this point, I had to more or less set the design style and standardise some of the reusable components to reflect across the admin site.

Breaking down each and every workflow with what needs to be gathered and what can be left out, I went on to build new mockups from the ground up. This project, unlike the audience-facing frontend, could not have been tweaked with minor improvements.

Much of the backend panel, had different data collection points at different sections. Most of which were quickly put together just to make it work well for that upcoming client’s event.

Design.

Just like all my other projects, I started out with some paper sketches, and a couple of reference materials mostly from Dribbble. Because this is almost like building something new, I had to make couple of iterations on paper, before settling on each and every screen.

Each screen took about a day to design entirely on paper, including planning and figuring out the design style along the way. This way, I could work towards something using software, and a reference of what I intended for it to look like.

Paper sketches are great, but clients do not see them the way you do.

As someone who has built a few products to date, I also realise, as powerful as paper sketches are, they do not necessarily mean much to clients. The measured pixels, the distance between elements, all of which are still customisable up to that point, will be ignored as work not yet started.

After much of the paper drafts were sorted, I started working on my trusted Sketch app and began laying out the different screens. Naturally, I designed each one, in order of how a user would go about doing the different use cases, in an orderly manner.

This method ensured that any time along the way, I can notice if there were any logical steps missing. Take it as mini-iterations with minor tweaks.

Development.

The one thing that I tried to steer away from, which I ended up repeating with this project, was to not make a major change to the same platform. Devs tend to use such instances as ways to buy big blocks of time to be uncontactable.

There is no harm in that at all. I firmly believe in being undisturbed when you are coding, especially features that are a re-do, where the logic remains just the UI is changed. But if there is no technical director, who is going through the commits and realising how far they are from finishing specific tasks, it will just drag on.

Time is money, even when the development is for upkeep and done during non-peak periods.

If the devs ask for 2-3 months in order to finish the revamp, as non-techies, there is little that you can say to shorten that. Terms such as migration, dependency injection, DB redesign, are common place when probed further.

Nonetheless, the execution was good. They were starting to show come progress, but the long periods of a lack of communication, also made things difficult for us to follow-up closely. At some point, the 2-3 months slowly got dragged by another few months. This saw a sluggishness in the delivery of this work as opposed to the more exciting products we built together over the year.

Ship to customer and their reaction

This is an ongoing project. Although some parts of the site are already done, the end users have not started using it yet. Much of the other use-cases had to be put on halt, at least until more online events start rolling in.

We toy around with the Beta version of it. So far, this has come a much longer way than the initial design which just seemed daunting from the get go.

When embarking on such redos, do not try and ship the whole thing at once.

Even during a revamp, always start the project as incremental changes. At least to your developers, this would seem like more attainable small changes that accumulates to be of higher yield. The sense of satisfaction from conquering each task also compounds.

Now the platform is already fitted with much of the tools all our users request. There has been a transition to maintaining the app, and only building features as and when clients request. Most at times, we take what clients ask, and try build it on top of our product.

In my opinion, this is not unethical as it is discussed from day one that none of the solutions are developed for a client to be the proprietor. In fact, I find it the best way to build your product with direct customer feedback. Everything is built on top of our platform, that would serve many clients much like themselves.

‍