Principles behind how we conduct design reviews at App Samurai

4 min readOct 21, 2019

It has been almost 8 months since I joined the App Samurai family. I wouldn’t even know where to start when it comes to things I learned here. My time in App Samurai is spent in a way not so different from my college years, constantly learning; both in the sense of product management and development, and of the ad tech universe. Before moving on with the main focus of this story, I want to portray what we do here in a couple of sentences. App Samurai is a mobile advertising platform connecting advertisers with publishers, helping advertisers acquire users, through its 300+ partners. Starting with the advertisers in the center of business, through the years App Samurai has evolved into a product family for publishers as well as advertisers.

Long story short, we challenge the biggest companies of tech in a compelling ecosystem with a great team, always exploring new horizons.

This story’s purpose is to tell one of my learnings, how I started to have a more design-oriented mind with a humble framework that we came up with, after spending quite some time researching design review processes and meetings. I love frameworks, I love putting things in order using them, I love the feeling after I approach a problem using each principle a framework includes. So, to keep everything that matters to us in place and be more organized, our decision to try this design review framework out excited me a lot. That being said, I want to emphasize the importance of proper design reviews in our situation. Why do we like it so far? It is easy to follow, usually implemented fast enough to catch up on our product development pace, and it is comprehensive for all our teammates, not just the product team. The way it is created has been another instructive experience: We applied this to one of our competitor’s main pages besides a few of ours and as a result, these experiments contributed hugely in ending up with the following 6 principles.

The Framework

We often ask a few main questions to apply the framework, and of course, the major questions are mostly followed up by minor ones to support one another. I believe the main questions listed below should be asked during the process, however the follow-up questions would differ with your environment, product and focus.

1. Simplicity

Simplicity is how we evaluate the design piece from the point of ease of use.

Is the page (could be a task or module) simple enough?
Can the user easily find what she is looking for?
Is the goal of the page is assumed correctly in terms of the user?

2. Clarity

We use clarity aspect to figure out if the design is easy to understand, more specifically we want to see if the user can comprehend what is going on on the whole page and in its sections. Clarity is particularly important if it is a critical component of the design.

Are the instructions on the page clear enough to help the user perform what is aimed?
Is the hierarchy of elements (if any) understandable?

3. Representation of data

If you are running a business that is centered around reports and dashboards like ours, you cannot unsee the importance of representation of data. This perspective to design could include assessing charts, statistics, tables or any other data visualization.

Do the data shown support the aim of the component or the page?
Is the data represented sufficiently?

4. Items of significance

This one gains in importance with the goal of the page. What is emphasized, highlighted and featured should be parallel with what we aim to show the user or make the user perform on the page.

Are the significant components addressed compatibly with the goal of the whole page?

5. Aesthetics

Aesthetics is the most subjective one among these aspects, yet it is definitely not less consequential than functionality. Aesthetic designs give a feeling of preciousness and ease.

Since it usually depends on the person evaluating the design, we prefer discussing aesthetics requirements in groups.

Does the page look so dense or sparse with data?
Is the design “good looking” overall?

6. Recommendations

Last but not least, we think of all the problems need to be solved. We discuss the recommendations to make the concerns go away. We make sure that we end the review with reasonable tasks.

Are there any concerns remain to be fixed?
What are the action items to be addressed?

We are well aware that there is huge room for improvement. It is not perfect and not a one-size-fits-all model, but it satisfies our need for now. We will learn as we experiment with it and find out the missing pieces, then add or remove principles from this framework, iterate through a better model.

My next post will be about how we applied this framework to one of our design works and how the process transformed the design.

I would love to hear what you think, please share your comments and thoughts!