Principles
Design
We believe great design principles help designers learn more about their design and make critical decisions about what they’re building.
We worked on few principles. Let’s introduce you to our UX design principle.
What, why, how of Design Principles
We at Practo, worked on re-defining our Design Principles. Why? Because the old principles were no longer relevant to what Practo is today & their awareness was extinct within the team. So here we are. Now, before we deep dive into how did we define principles & how you can also. Let us answer first the 3 fundamental questions
​
What are design principles?
Taken from invision’s blog : Design principles are a set of values that act as a compass for your product.
​
Why are they important?
They help keep your entire team on the same path as you move through the design process. Design Principles also guide teams with decision making. They help in onboarding new designers. And they act as an shared set of benchmarks for design evaluation/critique.
​
And how they should be?
Design principles should be specific, nuanced, and directional.
What should be the design principles based on?
Now the important part. How do we build our principles & how can you do so at your organisation?
​
In the very starting, when the forming design principles idea was being floated, we wanted to start from the starting. And there was 1 fundamental question that we thought to address : What is the pre-requisite to even start? (Can we define principles for both pre & post product?)
​
And the answer to that question is : understanding. And understanding can come in various forms. Like — vision is 1 form of understanding, insights is another, feedback is, and so on so forth. Now, depending on the company/product stage, this understanding can come in various forms as aforementioned, which in turn would have an implication on the extent to which your principles are rooted in reality.
​
Okay. So from where you build understanding can change, based on the situation. We went with feedback, because we have it as we already have a product, and also because, feedback brings the highest extent of reality with it (Quick Figma tip : If you import a .csv file to figjam board, your individual cell info would be directly converted to stickies). Our sensemaking universe was ready to deep dive into.
For other scenarios, it can be insights gathered from user interviews. Or at very high-level, it can be a set of observations you’ve made. The only needle that moves down here, is the extent of reality, but by acknowledging this & moving forward, you have the best possible guiding lights (design principles) for now. And you refine or replace them, when you have more understanding grounded higher in reality.
How did we kickstart?
Workshop based on feedback Channels:
Customer support tickets, Playstore Reviews, UT insights
We took help from our customer support team and collected all customer queries across our vertical product offerings. We also gathered findings from the usability studies done over the past year from our user research team and also took quick note of our app store reviews.
​
Next, we tried to go through all our collected data points. And we did a mega affinity mapping of the inputs. (the direct buckets are not your principles). And with the buckets, we had a good sense of ‘what’s going on’. And with these buckets, our next step was to extract our principles out of it.
mega affinity universe
How does actually defining 1 principle looked like?
Now, we had our affinity bucket. And as a next step, we were having intense discussion on our affinity buckets and trying to make sense of what the overarching principle should be, to really extract the lever which would move things.
​
For example : — Be faster than fast was a principle floated, extracted from our affinity bucket ‘respect users time’. But faster than fast was too vague. With no clear meaning to it, the direction we wanted to communicate was not coming out from this. Then, an alternate we thought was ‘Build a shortest possible path’. Now this is very prescriptive, we feared it would nudge the decision takers to optimise the flow for minimum number of steps, which is again not our intention here. The real truth here from our affinity bucket was : Our users are super high intent users. And both of the above said things, are either too vague or too prescriptive, clearly violating the benchmarks we set to avoid making bad principles.
​
Finally, we framed ‘Be sufficient, not abundant’ as our design principle. The clarity of this principle’s application will be super clear from the below explanation : — Now there are plenty ways of being sufficient, and it is up-to the current or future designers, to bring that perspective with them and apply it while designing. Our principle has done its job of nudging and subtly pointing them towards a direction. As a designer, your design can be sufficient in many ways, like say
-
by building a shortest path (the narrowness is at the execution level, which can vary from designer to designer, and should vary).
-
You can be sufficient by limiting the no of choices shown (hence making you faster than fast) so the principle guided you to make your design faster as a consequence, but just by saying faster than fast, would our designers would be nudged to sufficiency? Not really.
Application and impact to be updated.