Building a scalable system

Dive into how a dashboard was built and shipped for dubizzle.

How it all started?

dubizzle is a classifieds portal and I was taking care of the property vertical. Real estate agents would buy ad packages to post their properties and it was a good monitization channel. However there was always issues reported by CS and the team also had assumptions.

To clarify all of it, myself and Jermie, our PM visited 2-3 users every week to gather their thoughts. We did worked out some questions with the team before heading for the user interviews.

The concept of Refresh

For property agents, refreshing an ad means pushing the ad to the top of the zillion list of ads. This was quite an important feature in the line of business. They chose peculiar time to refresh their ads like weekends. This was the time when the site had more users.

To a certain extent, the team even had a good discussion on showing the users the right time to refresh based on their ads or selling it as a premium by making it all automatic. This was a good talk but we had to drop the idea as it needed more development resources.

The Challenge

Even though refresh was quite powerful, the users couldn't bulk refresh. We found this pattern in many users while interviewing them. Along with this, the ad management of different verticals( motors, property, jobs..etc ) looked quite different.

A unified scalable solution that can satisfy all the verticals.

This led us to the idea of building a minimal viable dashboard. We had around 2-3 sprints to achieve this.

Initial Wireframes

Some of the initial wireframes like the accordion were not scalable because it was not quite usable. On second thought, I had come up with something which would work regardless of any content. The context was more important.

Lesson 01 / 03 Context is important too

We always kept in mind that aim is to build a scalable system to give room for every other designer or developer the freedom to implement it in their vertical. I reviewed the designs with other PMs so that when we release the dashboard, there's less friction.

LESSON 02/03 Support the developer

Developers tend not to think the way designers do. So the latter should never expect that the former will understand all of their designs.

I had done some basic interactions for the team to get a bigger picture of the project and also created specs for the front-end to get started. Like I mentioned, this was only a starting. Sitting with the developer did wonders. I could see the roadblocks the developers faced and supported them. We also tweaked some of our A/B testings.

Lesson 03 / 03 Measure the success rate

If someone ask me about the most important question during the project, I would say it was about how we measure the design I've done is a success and how do we validate it?

Juny, our QA had the key to it. She was the gatekeeper of the team. At the start, she wrote over 20 use-cases and I even cross checked those with my designs. Once the project was deployed, we opened it to 10% to users. By looking at the log, we could see how many of the use cases were completed. But that's only one part of the equation.

A user can click on a button and we could checkmark a use-case but how they react to it while seeing the button and the way they interact with it could only been seen by user testing.

So myself and Jeremie, the PM visited couple of users. We let them use the product and we watched. Later took all those feedback to the team.

I'm always a believer that a designer needs to sit with the team and under their language. They need to understand the PM goals. the problems of the developer, the QA constraints and many more.

Based on that thought, I took our front-end to an user-testing session to show how users used the product he developed. He was pretty excited and I was quite happy to see that. Developers and QA don't always get to see users using their product and my goal here was to make it possible.

Bringing more clarity

What did this project solve?

The project solved many inconsistency in the design and allowed the product to be more usuable.

Did this project see the daylight and why?

Yes. It was launched in 2-3 sprints. Initially it was only opened to a fewer audience. later we opened it for everyone. Also there was many times when we had to revert back due to errors.

Who did you work with?

Conclusion

Other than the visual design part, working with a team and interviewing users excited me a lot. Hope to work on something similar soon.
chevronLeft icon Back to home Write me an email View the second case study chevronRight icon

Things I've learned

A weekly personal note about life and its teachings. Through setbacks and occasional wins, I’m still learning.

View previous articles