Building a scalable system
Dive into how a dashboard was built and shipped for dubizzle.
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.
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.
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.
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.
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.
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?
ConclusionOther than the visual design part, working with a team and interviewing users excited me a lot. Hope to work on something similar soon.