Over the last ten years of writing software at scale, we’ve become quite opinionated about how we work. Here’s how we code, the Obvious Way.

Over the last ten years of writing software at scale, we’ve become rather opinionated about how we work. We’ve seen good teams, bad teams, and good teams hamstrung by a lack of best practices.

All of our work is “country-scale”, which means it goes out to millions of people every day. A lack of best practices, growing developer teams, regression-related bugs and so forth mean that engineering progress often grinds to a halt. Where orgs have been built themselves entirely around a mobile app (think ride-sharing, m-commerce, neobanks, food delivery), the cost of having apps crash or be locked in technical limbo can rapidly rise to millions of dollars.

With that preface, we’d like to talk about some of the ways we think about building healthy, high performance engineering teams.

Engineering Philosophy

Engineering teams often think of themselves disconnected from both the rest of the organisation, and even further from customers who actually use the products. At Obvious, we’ve found that by situating ourselves as “co-owners” of the product experience, by looking at the overall org goals, and by expending effort to understand the impact of what we’re building helps us to get a better insight into the product.

Engineering exists within a broader organisation, and understanding that larger goal helps the team to predict requirements and find ways to make our end users happier. The only way that this happens at scale is if we remain highly aligned with organisational goals, with other teams, and most importantly, with each other. This ensures that we have the autonomy to explore different approaches, normalises failures, and enables trust at scale.

The Obvious Way

Most teams only take direct “costs” into account which are easy to see — time to build a feature, design a screen, migrate a database, etc. However, they fail to take into account indirect costs that come in as a product becomes mature — fixing regressions, identifying and refactoring pain points, improving developer experience, onboarding new hires etc. A lot of what we do at Obvious keeps all costs in mind and follow practices to keep them in check.  

Having a common vocabulary allows us to be efficient and avoids bike-shedding. Here’s what it looks like:

  1. Iteration Planning Meetings (IPMs): Evaluate what was (or wasn’t) done in the previous iteration and ensure that we all know what we are doing over the next iteration.
  1. Daily Standup Meetings (DSMs): We run a daily quick (~10 min) meeting everyday, to surface blockers or issues and keep everyone aware of what’s going on (at a broad level).
  2. Resilient architecture: In the rapidly moving landscape within which we work, it’s very rare for us to have visibility into the scale and future complexity that may be required. We distinguish between essential complexity and accidental complexity — the second is to be avoided, while the first, inevitable.
  3. Technical debt: Inevitably, we put something out that’s not perfect: requirements change, we write something in a hurry. We actively work on reducing friction by removing technical debt, even if it means a difficult conversation with another team or a client.
  4. Release cycles: Having a repeatable, predictable release cycle gives the rest of the org confidence that they can build on top of. This helps other teams factor in consistent engineering timelines into their estimates (whether sales, product or even customer support).
  5. Developer Experience: Understanding and enabling continuous success is an important part of scaling an engineering team.
    1. Code reviews: At the team level, having regular code reviews ensure that standards and guidelines are followed and for feedback on ideas and approaches to be shared.
    2. Trunk-based development: Avoiding “merge-hell”, reducing distance between developers (which branch-based development does) and setting the stage for continuous review, integration and deployment are key reasons that we practice TBD.
    3. Regular, readable commits: We absolutely avoid massive code “dumps”, and do frequent (daily) commits, along with good commit messages. This speeds up code review, writing release notes and helps future maintainers (and you!) understand why you did whatever it is that you did.
    4. Project management: Pivotal Tracker is our current go-to for managing complex software projects. You’re welcome to look through the Pivotal board of one of our active open-source projects, which is representative of how we use it.


We’ve seen some encouraging results from this approach. Our small — 2-3 people — teams have consistently punched above their weight. We now regularly build products which reach populations in the mid-to-high tens of millions. At that scale, every single product and engineering iteration has the possibility of unlocking massive business value. Our clients now bring us in to help them set up these practices within their own teams, in addition to helping with mission-critical systems.

Like what you see? We’re hiring!

If the Obvious Way makes sense to you, let us buy you breakfast. We’ll tell you more about the work that we do, give you the lowdown on life at Obvious, and answer any questions that you might have about engineering or working here. Or jump straight in, and apply to join our team!

Read more

When I joined Obvious, Simple — an open-source app for clinicians to track patients with high blood pressure — was in beta, and since then has been at the heart of my work. I’ve been working on the app for more than a year now, and it has been quite a journey! The team has three Android engineers, and our work has found a sort of daily rhythm that we’ve figured out along the way, with some trial and error.


9:41 AM

My usual workday starts while I am in the cab and on my way to the office. I live quite a while away, and Bangalore traffic being what it is, this is an excellent opportunity to get some work done! I fire up the “Sandbox” app on my phone and update it. I quickly test a feature that was merged yesterday. The feature is for our target users who are nurses working in rural India, enabling them to follow up with patients quickly. Looks like it’s working well, which is my cue to post on the Slack #releases channel that the feature has landed on Sandbox so that the design team can test it out.


10:17 AM

Once I reach work, I grab a cup of coffee on my way to my desk, located in the “quiet zone” designed to help us get deep work done. After going over my Slack messages and responding to a few, one of my teammates’ asks me to discuss the code review feedback I left for them. So we go into a meeting room and collaborate on refactoring a piece of code that was increasing our code complexity. After a few minutes, we figure out a way using Kotlin’s beautifully designed APIs. LGTM!

I look at my open pull request from the day before, and it is still under review. Since we follow trunk-based development, I cut a new branch from the branch under review, and continue working on the feature. An iteration in this project is usually a week-long, spanning Monday to Friday. We cut stories for each feature and make sure that one story is never worth more than 3 points (points being a mark of effort and not complexity) because only so much can be estimated by an engineer!


11:55 AM

I start by writing a test to verify a small feature using the given-when-then representation. Ever since a senior engineer helped me start on Test-Driven Development (TDD), I have been pushing myself to write tests before I even think of implementation. After adopting this approach, it has allowed me to follow a more user-driven approach to building software. I run the test and it fails — of course! — because the code is missing. So I go ahead and write a small piece of code to make it work. I commit once the test passes and then refactor the implementation a bit and run the tests again. Make another commit. And this goes on for about an hour till lunch.

By 12:30, most of us are eagerly waiting for the Slack notification that food has arrived. Lunch is often a chatty affair, with discussions ranging from public transport to culture to street food. Since Obvious houses both design and front-end engineering teams, we also end up spending considerable amounts of time discussing one common critical aspect of our work — user experience.


2:10 PM

Lunch is over and one of the designers wants my opinion on something new that’s being added to the flow. They are trying to figure out a way to de-duplicate entries in the system by allowing users to identify and delete the duplicates. This is where the real advantage of having both designers and engineers working at Obvious comes to play. We are able to minimize our feedback loops immensely by collaborating more often. This helps designers translate their user-centric design to a final product and helps engineers be closer to the users, by doing more than just writing code.

One of our engineering philosophies is that “we review code before we write code”, so after lunch, I dedicate some time to reviewing assigned PRs. This also helps me contribute by doing work which does not require deep focus right after a good lunch. I also go over other PRs which gives me a sense of what’s happening around the project.

While we are on the topic of reviews I want to mention a cute habit which I have picked up recently from a teammate — we drop small positive comments or emojis in the open pull requests and especially on ones that are not assigned to us for review. It’s such a small thing in terms of effort but it goes a long way in building trust within our team.


3:49 PM

We don’t have stand-up today so I continue on the feature to introduce diabetes management into the app. It is a long-running epic so it will have multiple stories and PRs. All of this code is hidden behind a feature flag while in development. So the feature may not actually work right now but our CI workflow ensures that code compiles correctly. We can never break the master branch, and this enables continuous delivery.

I receive a Slack notification that my PR from yesterday has been reviewed and I need to address the feedback. So I pause working on the new feature and first close the requested review changes — remember, “Delivering code already written takes preference over writing new code”. I wrap up work until the end of the day and push today’s branch to raise another PR. And the cycle continues 🙂


6:06 PM

We have come a long way in just one year. Simple is now launching across India and in other countries, and lots of credit goes to our team processes, developer habits and work ethic. At the end of the day, I go home proud of what we’ve achieved and even a terribly long commute doesn’t look that bad!

We’re Hiring!

If the Obvious Way makes sense to you, let us buy you breakfast. We’ll tell you more about the work that we do, give you the lowdown on life at Obvious, and answer any questions that you might have about engineering or working here. Or jump straight in, and apply to join our team!

Read more

One year after launch, see how the Simple app helps nurses to save lives from heart attacks and strokes.




On this day last year, I was sitting in a car driving down a beautiful rural road in Punjab, India, through a long tunnel of trees with rice paddies on either side. We were headed towards a public hospital and my teammates and I were anxious and excited since it was the first time that the Simple app was going to be deployed for real in a clinic. Would the app perform well? Would the clinicians accept it?

This was not my first time arriving at a hospital on this project. During the early development phase of Simple, we visited clinics many times to test prototypes. This time, though, it felt different. We had a beta version of our new Android app and we planned to install it on clinicians’ smartphones. It was the very first time the Simple app would be used in a live clinical environment to record real patient data and our software was competing with the tools that our users were already super familiar with — pen and paper. Bear in mind that on a typical day at a public health facility in India, a clinician sees over a hundred patients (average consultation times are less than 5 minutes). If Simple was going to be successful, it not only had to be as intuitive as pen and paper, but also had to be a lot quicker, which is a huge challenge. That first deployment went really smoothly. The nurse and doctor picked up the concept quickly. The app performed well. We breathed a sigh of relief.

A doctor recording patient visits using Simple

During October, 2018, we deployed Simple in 20 more clinics. A WhatsApp group kept us in touch with our early users and helped us maintain a short feedback loop to uncover and fix issues. It was inspiring to see how quickly nurses and doctors got accustomed to using Simple to record patients and how the app could help them recover hours of their precious time. Before Simple, clinicians spent a couple of minutes just to find each patient’s paper treatment card from a stack of hundreds, but now users only had to enter a patient’s name into the app to look up their record. Simple reduced the time to record a patient from 4–5 minutes to about 45 seconds. Over the last year, we made frequent, iterative improvements. We prototyped and tested constantly. And, we released new versions about every two weeks. In May, we introduced a scannable user ID called a “BP Passport” which has reduced data entry time to 24 seconds on average. Clinicians can now spend more time actually treating and counseling patients, rather than recording data.

One year after launch, Simple is used in over 400 hospitals and clinics to manage over 145,000 patients. To celebrate this one-year milestone and to acknowledge the work of healthcare workers who are doing the hard work of treating patients, we created a short film that tells the story of a day in the life of Bhupinderjeet Kaur, a nurse at Sub-district Hospital Batala in Punjab. Nurse Kaur uses Simple to manage her patients with hypertension and she takes a lot of pride in playing her part in reducing deaths from heart attacks and strokes in her village. In 2020, we anticipate that Simple will be deployed in many more hospitals across other Indian states and we will start deployments in several other countries soon.





Thanks to:

  • Nurses Bhupinderjeet Kaur and Ranjit Kaur for letting us follow them around and shoot them for two days.
  • Harnanth Singh, for inspiring us with the story of his hypertension treatment and for allowing us to shoot at his beautiful farm.
  • , Assistant Director, Punjab Health Department.
  • Everyone who works as part of the India Hypertension Control InitiativeIHCI is a multi-partner, 5-year initiative between the , State Governments and  Country Office for India.  (an Initiative of ) is an international technical partner.
  • Daniel Burka for script writing and for editing this article.
  •  for tirelessly shooting and editing this film 🙌.


Read more

Simple is an app for hospitals to manage their patients with hypertension. At Obvious, we are responsible for designing and conducting user research for Simple, as part of a larger team based across Bangalore, New York and Delhi.

Since deploying in October 2018, the Simple app is being used by healthcare workers in over 400 public health facilities in the states of Punjab and Maharashtra, India as part of the India Hypertension Control Initiative. Many of the public hospitals where Simple is used are in remote towns and villages.

As the product team, we care deeply about how the app is faring on the field: 

  • What are the most pressing issues faced by the users?
  • Is it making their work easier and better?
  • Are there important user needs that we haven’t thought of?

Without regular interactions with the people who use our software, we can’t know the answers to these questions.

It might sound basic, but regularly scheduled phone calls bring us closer to our users and help us identify patterns of concerns among our users. In fact, the phone calls are one of our most effective ways to keep our fingers on the pulse of Simple in the field.

Here are the key aspects of our interview process that get us helpful and actionable insights:

Create a safe space, quickly

If we want to gain authentic feedback from users, the first step is to create a safe space for them. We focus on creating a safe space quickly. This leads to the conversations being very effective — we learn a lot in a very short time.

Within the first one minute of the call, we establish that we intend to listen to them. We pay attention to their words, tone and underlying emotions — and we ask relevant follow-up questions. We ‘reflect’ what we hear to confirm our understanding of the users’ experience and to help them feel heard.

We listen in a way that makes it clear that the person we are speaking with is more important than the software we are building. We are interested in the details of their everyday work that they talk about. We are interested as they share about the issues that they face — both related to the app and to the broader context of their work.

This enables the users to share honest feedback with us — both positive and negative — and that is really valuable.

Keep the interviews short

Our users are busy people with demanding jobs. A phone interview does not need to be exhaustive. A short interview (we do 10-15 minute phone calls) will help you narrow down your questions to the key issues. Short interviews also mean faster synthesis afterwards, so your regular cadence of interviews won’t become a burden to you and your product team.

Structure the interview

The interview is structured to ensure that it flows well, is not rushed, and that we cover all the questions that we have planned for. Here is what the structure looks like:

1. Introduction

In this we introduce ourselves, explain the purpose of the interview, and check that they have ten minutes to speak with us.

2. Initial question about interviewee

We ask them about their role and their primary responsibilities at the hospital that they work at.

3. Feature usage questions

We ask them about their use of three primary features of the app. We learn about how they use these features, and if they are working well for them.

4. Satisfaction rating

We ask the user to rate the app between 1 and 5. We ask them to support their rating with reasons. We ask them to share what they like about the app and issues that they are facing related to the app.

5. Conclusion

We ask if there’s anything else related to the app that they’d like to share. We ask them to share any further issues on the support group. We thank them for their time.

The key is to be listening intently to the users throughout, while ensuring that the interview progresses according to the structure. Additionally, we want to keep the length of these interviews to be less than 15 minutes because 1) healthcare workers have busy work lives and 2) to keep our telephonic interviews process lean and inexpensive.

Here is the interview guide that we use.

Keep a regular cadence

Me and my product team are busy. I bet yours is too! The only way we keep our interviews on the rails is by scheduling them ahead of time for the whole year. Block off your calendar for a couple of days on a consistent schedule, explicitly for conducting and synthesizing your phone interviews.

It’s key to maintain a regular cadence — we call users every 3 weeks. We ask a consistent set of questions to be able to track the progress of the performance of the app over time. Each time, we select one of the districts where Simple is deployed and speak with 5-6 active users of Simple from the district — this helps us find patterns.

Ask the same (or similar) questions every time

We ask a consistent set of questions every time. These help us evaluate the performance of the most important features of the app over time, and also across locations as we continue to scale.

For example, back in January 2019, the patient search feature was causing the most issues for users in Punjab. Since then, the Simple team has made several improvements to patient search including introducing a scannable patient ID. In interviews conducted in October 2019, we received extremely positive feedback on the improvements. 5 of 5 users of the district shared that they were using the new features  to find patients and they no longer faced issues in finding the right patients in the app.

Through asking a consistent set of questions over this year, we have been able to track the progress of the key features of the app.

Stay in tune with the product team

The focus of the phone interviews is to get feedback and findings that are both current and relevant. This helps us move fast as a team.

When we release a new feature or a big change, we include a relevant question in our next interviews. Learning whether the feature is working well and how the feature is being used helps us make decisions on improving the product.

When we released the “Recent Patients” feature (a list of the recently visited patients that is displayed on the home screen of the app), we spoke with users to understand how they use the feature and if they use it at all. We learned that it was being used in a variety of ways and some that we had not anticipated while designing the feature. This understanding helps us iterate on and refine our designs.

Later, during our field visits, we observed the use of the feature and further strengthened our understanding of it.

The Android engineering and design teams during a regular stand-up meeting.


Collate satisfaction rating along with the supporting ‘why’

We ask each user to give the app a rating between 1 to 5. We ask them to support their rating with reasons. This question is asked towards the end of the interview to ensure a comfortable space has been established.

We share these ratings with the team every time we conduct the interviews. Additionally, every few months, we do a collation of these ratings. See the consolidated ratings from June 2019.

Users who gave the app a rating of 3 or 4 gave it because they were facing issues while using the overdue list feature or while looking up patients. Users who gave a rating of 5 stated that the app worked well work for them, and it had simplified as well as enhanced the quality of their work.

These satisfaction ratings are a metric that we want to continually improve.

Phone interviews should be part of a larger effort to learn from users

Phone interviews complement our other customer support and user research efforts. Issues reported to customer support are initiated by users — in the case of phone interviews, we are proactively reaching out to users. This means that sometimes we are a step ahead of finding issues in the field. Secondly, it helps us reach out to people who otherwise may be uncomfortable or may be too busy to post concerns proactively. When we visit the field (which we do often), we can validate the findings from the phone interviews.

Observing a nurse at a PHC in Sindhudurg, Maharashtra

Over the past year we have reached out to 50+ users across all of the 7 districts that Simple is deployed in. Phone interviews have established a continual feedback loop between the product team and the users of Simple. They are a foundation for our product development process because they keep us in close touch with our users over time.

Through conducting these interviews we’ve learnt that if you create the right environment and with a strong plan, you can learn a lot from a short 15-minute phone conversation. If you maintain a regular cadence and collate the findings on a regular basis, the interviews will provide excellent insight and direction for your product.

Thanks to Padmini Ray Murray and Daniel Burka for editing this article, and to Anand Rama Krishnan for the photography.

Thanks to Daniel Burka, Dhruv Saxena, Akshay Verma, Pragati Mehrotra and Mahima Chandak for their valuable inputs to the phone interview process over the last year.


Read more

As the next wave of Indians come online for the first time, digital technology is having wide-ranging impact on their aspirations, their behaviour, their societal structures and their consumption patterns. We are collaborating with The Hard Copy to bring our readers stories that detail the changes emerging resulting from the rapid adoption of technology by the next billion users in India.

Obvious has three core values: craft, context and community. In order to be true to these values, we need to commit ourselves to understanding complexity. Next Billion Stories will raise the bar for deepening our own understanding of complexity, by exploring, investigating and critiquing how technology and design does, can and will shape the world we live in. We hope it will inspire us, and our readers, to think of creative and strategic ways to respond.

Themes that will be explored (but not restricted to):

  • The Gig Economy
  • Future of Interfaces
  • Global Tech, Local Users
  • Social Media
  • Financial Inclusion
  • Intersections & Infrastructures

Here at Next Billion Stories, we believe that it is critical to examine these changes through a contextual design lens to better understand how to serve this population. These insights are vital for anyone addressing the next billion, be it designers, businesses, developmental organisations or policy makers.

If you are a researcher or writer with an interest in this space, we would love to hear from you and explore how we can work together. Do send in a few details and we’ll be in touch.


Read more

By Mahima Chandak

Manjeet was counseling a patient with high blood pressure when another patient jostled through the crowd and asked her to hurry up. Each patient was impatient to get back to their own busy lives. Everyone in the hospital today was rushed, just like every day at many overworked public hospitals in India and around the world.

Our team works on a piece of software called Simple, which is designed for nurses like Manjeet. Busy nurses with many patients. They use Simple to manage patients with high blood pressure, with the goal of saving many lives from heart attacks and strokes.

Keep in mind, clinicians don’t especially want to invest their time in an electronic medical record. Nurses and doctors didn’t come into work today to fill a database. They came to do the important work of treating the patient sitting in front of them. If we want Nurse Manjeet to use our software, we must understand the working lives of nurses like her and fit into them as seamlessly as possible.

So, our team spends a lot of time in the field observing healthcare workers and asking for their help.

When we talk to healthcare workers about their workflows and how they use Simple, we are looking for patterns. Hearing a concern once is useful; hearing a pattern of concerns is really helpful. How can we effectively communicate these patterns to the entire product team so we can make better product decisions together?

Our challenge was to bring lessons from the field into our office, so our developers, designers, and product managers can empathize with nurses and prioritize our roadmap. Inspired by Airbnb’s ‘Snow White’ project, Simple’s Design Director Daniel Burka suggested a visual, data-driven storyboard that illustrates the key parts of the user journey. The storyboard is now a crucial component in our product process.

See the final storyboard here.

How to create a data-driven storyboard

1. Choose your protagonist and her story

The first step would be to choose the primary user whose story you are narrating.

Simple is used by many types of users: nurses, doctors, pharmacists, counselors, and other healthcare workers.

We chose to tell the story of Manjeet, a fictional staff nurse working at a public health clinic who is new to using software and apps. We chose her because she represents the largest group of our users and the most crucial users for us to satisfy.

The narrative is an end-to-end story of how Manjeet hears about Simple for the first time, her thoughts as she learns to use the app in her workflow, and how she ultimately teaches a colleague to use Simple. Keep in mind that your story isn’t only about how someone uses your software — it also encompasses your user’s overall workflow.

Persona of Simple’s primary users

2. Identify the key moments in the user’s experience

Select the key moments that describe your primary user’s interaction with your product in her context. We created a list of all the different user scenarios, and then grouped them, categorized them and prioritised them.

Prioritise the moments that occur most commonly and emphasize aspects of the user’s experience that need the most focus from the product team.

For scenarios where multiple workflows existed, we focussed on what either needed the most support or was most common. For example, there are multiple ways in which a nurse can hear about Simple. It could be through a memo, during a training session, or from another nurse. In our final storyboard, we picked the scenario where a nurse is instructed to use Simple through a memo. This scenario is especially challenging: How can a nurse learn to use the app by herself, without any prior training from her supervisors?

Warning: Avoid focusing only on the digital interactions between a user and your product. Remember to also include offline experiences that glue together your product in the story.

For example, we chose scenarios that depicted both online experiences like onboarding, registering a new patient, and making overdue calls, as well as offline experiences like patient treatment, being called out of the room for an emergency, and juggling several tasks at once. Offline and online experiences make up a nurse’s day and if our product falls apart when our users lose focus, our product will be useless.

Finally, we ordered the key moments so each frame independently captures that moment but also so when they’re stitched together they tell a meaningful story.

3. Sketch the key moments

As you sketch each moment, keep the user’s experience, front and center:

Refrain from giving the product more importance than the user. And, focus on capturing the essence of the moment, without limiting yourself to what seems possible to solve.

Stay close and truthful to the research data. For each frame, we pulled out the findings that we developed from user research. We depicted the details of her environment: ‘What does her table look like?’, ‘How does she interact with her tools?’, etc.
We made rough but realistic pencil sketches of the eleven key moments.
We wanted to stay close to the user’s actual experience: ‘How many patients will a nurse be attending at a time?’ ‘What are the tools a nurse uses for his/her work?’ ‘How old are the patients who visit the clinic?’ ‘What do patients carry along with them?’ ‘What is the conversation between the nurse and the patient?’ ‘What time of the day would it be when a particular moment took place?’ ‘What are the character’s thoughts?’ ‘What does the nurse’s environment look like?’ ‘What perspective must a frame be depicted in?’

4. Focus on your users’ concerns

Below each scenario, list down your users’s concerns. This puts readers into the user’s context and enables product teams to set clear goals. Remember to only add concerns from research data, and refrain from adding concerns that you anticipate the users might have.

Each frame of our storyboard has a list of the most common concerns that we have heard from users and stakeholders in the field.

While many concerns can be tackled through the design of the product, others form touchpoints within a service that product teams must strive to design for.

5. Create the final illustrations

After having consensus from the team on the depiction of the frames, we then made the final illustrations.

We made the colour and style of the protagonist’s clothing bright, so that she stood out in each frame.

We also kept the style of the illustrations relatively simple. If your illustrations are too fancy, you will have a hard time changing them later when you find out that a detail is wrong or you want to add another frame to your story.

6. Publish the storyboard where everyone can refer to it

It’s really important to publish the storyboard in a place where everyone on your team can reference it while they work. Ideally, the storyboard is easy to edit as you learn more from the field and as your product changes.
We published our storyboard on our documentation site (we use GitBook). And, we also printed out each frame and hung them prominently on our walls in our workspace.

How did the storyboard help us

Each time we make design decisions, we can go back to the pain points and try and address them through the design of our service. Our product must address as many of these concerns as possible if we hope to help thousands of clinicians to save millions of lives. It also helps to remind us that software isn’t the only solution required — we also need great training, support, and marketing.

For engineers and others who aren’t frequently in the field, the storyboard has really helped to build more empathy with our users and gives them context when they’re making decisions.

“Since I’m new to this project that has been running for a year now, the illustrations were helpful in immediately putting me into context.”
– Ragunath, Android Engineer, Simple

The eleven frames of our storyboard are a reminder of what we’re really building and how it affects our users. Moving forward, we aim for the storyboard to be a tool that fosters the participation of all stakeholders in the product design process, helping us all to make good decisions.

This article is co-written with Tanushree Jindal, without whose valuable input creating the storyboard would not have been possible. Thanks to Daniel Burka for his help in writing and editing, which helped us strengthen the article.

Special thanks to Dr. Terry Cullen and Dr. Greg Schmidt for reviewing and editing the article, and to Anand Ramakrishnan for the photography.


Read more
With thanks to the Indian Design Community, where this piece was originally published.

Dhruv heads the design practice at Obvious — a digital product design consultancy that has helped many of India’s and SE Asia’s unicorn startups — Go-Jek, Flipkart, Myntra and Swiggy to name a few– achieve rapid exponential growth through design.

At Obvious, Dhruv helps clients use design as a foundation alongside business and technology to build products that people actually want to use.

In a previous life, Dhruv’s work focused  on designing tangible interfaces, which he built through collaborations with designers and professors at the Copenhagen Institute of Interaction Design (his alma mater), MIT Media Lab and Stanford.

Dhruv, we would like to know about your journey building Obvious and also about rebranding Uncommon to Obvious.

It all started in 2012, when smartphones started seeing a meaningful participation in the Indian consumer market. They began penetrating the lives of people through the convenient services they supported. Access to products like maps and e-commerce was life changing, and it wasn’t long before everyone started realising the benefits of carrying a computer in their pocket. Around the same time, Uncommon was born.

Uncommon was the child of luck and intention. We were lucky that we started right at the beginning of the smartphone boom, but we made an intentional choice to focus only on building beautiful and performant mobile applications. This union of luck and intention, combined with the success of some of our early clients like Flipkart and Myntra gave us a name. We were the new kids on the block, but we were playing with the big boys in the Indian startup ecosystem. Whatever we were doing was working, but we were quick to realise that it wasn’t going to last forever.

For a services business, a few stand-alone successes aren’t enough. If we were going to deliver successful outcomes to every client we worked with, we needed processes and frameworks that could reproduce success time and again. Uncommon could not operate merely through luck and intention anymore. It needed structure, it needed organisation.

We started creating processes around our design and engineering practice that could guarantee successful products. Very quickly we realised that a tight practice alone is not enough, the people who use it are equally important. So we started building strong people practices, which sent us down the rabbit hole of career frameworks, employment policies and more. Every-time we touched an area of work, we realised that the existing status quo needed to be challenged, so challenge it we did. With our heads down, we went ahead in full steam, inventing and reinventing methods until we were satisfied. Though completely worth it, the process took longer than we had imagined.

Fast forward to 2019, when we finally lifted our heads and looked around, a lot had changed. While we were now known for some of the best practices in the industry and had grown into a strong creative organisation filled with talented individuals, our small size still severely limited our ability to serve everyone who reached out to us. We were proud of what we had achieved, but dissatisfied with how much we were doing.

Turning down 9 out of 10 interesting businesses that wanted our help and were even willing to wait a couple of quarters just for us, felt like we weren’t doing our part. It meant that we were undeserving the very ecosystem that had made us successful. It meant that we weren’t investing enough into the machinery that was keeping us relevant. It meant that it was time to rethink our future.

If there was one thing that we were really confident about, it was that our methods and practices lead to the creation of successful digital products, and we wanted to see more of them in the market. By setting ourselves up as an alternative to mainstream ways of thinking about software — we wanted to be, and were, uncommon. But now, our mission was larger.

We asked ourselves — How might we serve not just our immediate clients, but the larger tech ecosystem we inhabit? How might we enable everyone to benefit from our practices and the ways in which we run our organisation? How might we stop challenging the current status quo of how digital products are built in the country, but instead become the new one?

The answer to all these questions boiled down to one key idea — it wasn’t enough to be just Uncommon anymore, we had to be more Obvious.


What are your processes and secret recipe for success?

Our recipe for success isn’t a secret, it’s well documented in our open source playbook.

We’ve written about everything from our engineering and design processes, to the way we run our meetings, our one-on-ones, our feedback sessions and more. We know that we can’t serve the whole ecosystem, but if someone finds our way of working interesting, they can build on it and create an even greater impact than we have.

As a company what has been the hardest thing to do?

Scaling Obvious without compromising quality has been one of the hardest things we’ve had to do. In a market driven by startups that promise quick and disproportionate returns to talented people, convincing them to join a small mission-focussed organisation is quite a challenge, but we haven’t done too badly for ourselves.

Our approach towards solving problems is both practical and academic. This mindset has helped us build scalable frameworks that deliver solutions which are quick, but at the same time have a lot of depth. None of this would be possible if it weren’t for the talented yet humble people at Obvious, who have consciously chosen to invest in long-term career growth and learning over short term success.

Could you tell us more about the hiring process at Obvious?

Most organisations hire people based on their previous role and compensation, but not us. Our salaries are fair and equitable, which means everyone delivering the same value gets paid the same. To fairly identify what value a new hire might bring to the table, we take them through a 3 month apprenticeship program where we immerse them in our ways of working. This helps us as well as the new hire, understand their value in our organization, based on which we offer them a position. Not only does this process ensure that we don’t hire someone who looks good on paper but can’t deliver high quality work, it also helps fairly compensate people who do not have the negotiation skills to demand a salary they truly deserve.

How do you ensure people at Obvious keep growing in their careers?

We’ve borrowed quite a bit from tried and tested frameworks created by companies like Medium and Adaptive Path. Our career framework allows individuals to choose areas of growth for themselves. It is possible to grow in craft, management or both. People in our team are multi-faceted; forcefully reducing them to individual contributors or managers hampers their growth instead of boosting it. We ensure that people are mentored and get help to not only think about work but also about how it fits within the larger picture of their whole life through regular one-on-one conversations. We also do career conversations every six months which help people gain clarity about their growth trajectory by developing a custom-tailored growth plan based on their medium and long-term aspirations. For work related feedback, we do feedback conversations which help create an opportunity for consistent growth as well as a chance to establish deep, credible relationships.

Do you have a remote-working system at Obvious?

Our work is very collaborative and requires a lot of context switching, which is better addressed when we don’t have artificial boundaries between us. We used to be a remote first company but over the years we’ve realized that collaborating with each other in person keeps us more excited about work.

Having said that, we do encourage people to be judicious and save whatever time they can by working remotely even when they’re in the same city. Saving just an hour in commute everyday is equivalent to saving over 30 working days every year. We want to ensure that our time is better spent, for which we’re constantly experimenting with remote collaboration. So yes, we do have a remote working system, but we deeply value coming together as a team every single day. It keeps us energised, it makes us tick.

As an organization, are there other companies you look up to?

We are lucky that we have a network of phenomenal people who’ve helped build amazing organisations of all scales and sizes. For instance, Daniel has helped us learn about culture and practices at organisations like Google Ventures. We’ve also been in conversations with some other design-first organisations like Netflix, Twitter, Grab etc. Each one of these conversations has positively influenced our direction.

We’ve also been a part of some amazing home-grown success stories like Flipkart, Myntra, Swiggy, Go-Jek etc. We have strong relationships with the leadership in these organisations and their mentorship and support has contributed phenomenally to our growth and mindset.

To top it all, we also have strong relationships with some amazing minds in academia from world-class institutes like Stanford, MIT & CIID.

What is your criteria for taking up new projects?

We evaluate new projects on a 3X3 matrix of Challenge, Impact and Novelty. Projects which score highly on all 3 axes are the most exciting for us.Constant learning is an important theme at Obvious; to support that we try to strike a healthy balance of projects from diverse domains. We’ve been lucky to have touched at least one successful product in almost every domain that exists in the market today. Our strength is that we’re able to cross-pollinate ideas from one domain to another, which has contributed tremendously to the success of the products we’ve helped build. The promise of building something new, that solves a hard problem, and can lead to amazing impact on the world we inhabit, is what makes us all come to work everyday.

Obvious has been trying to build communities and has been supporting and encouraging various community activities in tech and design. Could you talk more about that?

We started Obvious because we were all very craft-focussed and we wanted to prove that great digital products can come out of India, which is why most of our work was also very India centric in our early years. We soon realised that craft is meaningless unless its application suits the context within which it resides; so we worked within a lot of different contexts to deepen our own contextual understanding of design.

While we had built a strong practice at the intersection of craft and context, we realised it wasn’t enough. There was another key ingredient that needed to be added to the mix, and that was community.

Our work on community has just begun, and we hope to do a lot more. Last year alone, we gave 16 talks across 4 different countries. We’ve published all our methods and practices in our open source playbook. We’ve been running women-only tech events like Womendroid. We’ve been seriously considering investing in a strong fellowship program for design education. We’ve even created a huge space in our new office for free community events. Like I said, we’ve only scratched the surface of what can be done for the design and tech community; we hope to go much further.

What are other things that have shaped you in your career?

I don’t really have an inspirational story for you, but I might have a funny one. After a year of education in industrial design, I figured design wasn’t my cup of tea. I had made up my mind to quit school and join a friend’s startup.
My then girlfriend (now wife) talked some sense into me and convinced me to continue my education. That moment became the tipping point in my early career. Up until then, I was reserved about my ideas, trying hard to meet the standards of my exceptional classmates, but the moment I decided to quit, I felt that I had nothing left to prove. I broke free of the impostor syndrome most young designers struggle with.Luckily, although I decided to stay, the feeling that I had nothing to prove also stayed with me. That made me far more inquisitive and far more experimental in my work. I entered some not-so-hot domains like hardware and tangible media. Prototyping hardware is hard; you almost never get it right the first time. The mindset that failure is not really failure, it’s success because you now know what not to do, made me a very secure designer with an appetite for high risk.
I was very lucky to have found partners (Rahul and Pratul) who support this kind of thinking. Together we’ve shaped Obvious into an org that has a very similar mindset towards failure and risk taking. That mindset makes Obvious a very unique place with very unique people, who further continue to shape me into a better designer and a better human everyday.

Tell us more about your experience at CIID?

CIID is great. It has very strong foundations, which is not surprising because people like the late Bill Morgridge, and Bill Verplank, – the duo that coined the term interaction design, have been teachers at the school. The education model is very unique and pragmatic. The learning is externally focussed, and is evaluated based on the real world response to prototyped ideas rather than written exams. The peer group is really inspiring, and is usually filled with people who have already done a lot in their careers. For example, the average age of my class was above 30, and the life experiences of my peers ranged from writing public policy at the UN, to winning an academy award for designing artwork for The Grand Budapest Hotel. I was definitely the least qualified person there :).

Any daily practice that you have for yourself?

Life in a creative field can feel very disorganised, but it doesn’t have to be. To keep my sanity, I use a basic GTD framework – nothing super complex, although people who know me disagree!

I also believe very strongly in Deep Work, so I try to start early and get some deep work done in the first four hours of my day. After that I spend most of my time with the team doing collaborative work and problem solving.

What according to you are 3 ‘must have’ skills in designers? Can you recommend some books that might help build those skills?

Apart from doing good design which involves things like great product thinking, a solid understanding of business, high production quality etc,  I ask designers at Obvious to focus on the following:

1. Articulate your design decisions

Doing good design alone is not enough. You also need to convince people of its value. If you can’t articulate why something works or doesn’t work in a convincing way, why put in the effort to build it in the first place? There’s a lot of great literature out there on the subject. One of my favourite books on the topic is Articulating Design Decisions.

2. Keep it obvious

Beauty lies in simplicity. Everyone can add something, but successful designers keep simplifying until there’s nothing left to take away. Dieter Rams mastered this art. Apple’s phenomenal success is also often attributed to this trait. However, most people miss that the combination of beauty and simplicity is extremely difficult to achieve. There’s a lot of writing on Rams that explains this idea. My favourite one is Ten Principles for Good Design.

3. Be ready to play more than a designer

The job of a designer isn’t just creation. Sometimes designers need to get out into the field to learn from users, sometimes they need to write documents or code up a prototype, sometimes they need to work with engineering to ensure designs go to the users as intended, sometimes they need to work with other business departments to create business alignment, and sometimes they need to crank out some good old fashioned design work. There isn’t a book that covers all of it, but for anyone who wants to dig deeper into the idea, Design is a Job is a great starting point.

Lastly, what challenges are you looking forward to in the future?

The list is long and never-ending, but in the near future, we’re focussed on a few things.

  1. We want to ensure that we walk the talk, and continue to deliver on the promise of a creative workplace where we all come together to do deep, impactful work. Building great culture is hard, but sustaining it, even harder.
  2. We want to offer people the opportunity to grow well financially while doing the work they find exciting. As a small organisation, we can’t beat the short term financial promises made by hyper-growth startups, but we’re doing our best to ensure that the long-term benefits of working at Obvious are as much about financial growth, as they are about doing meaningful work.
  3. A lot of our work used to be focussed on building things the right way, but now our larger focus has shifted to building the right things. To this effect, we’re running a lot of experiments. For example, we’re building a framework that can help us run qualitative user studies at scale. Rather than testing prototypes with a handful of users, can we build fully functional apps with real instrumentation that can be left with 20-50 users to learn about their behaviour for a few weeks, without investing the kind of effort required to engineer a real, scalable application. Building such frameworks that can be employed repeatedly is challenging, but exciting!

Overall, we’ve been able to get some great minds to work with us, and my sincere hope is that we lend great thought leadership to the field of design, technology and digital humanities in the country. We know that the future is filled with challenges, but given the kind of people who have joined the cause of Obvious, I am very positive that we will not just meet, but exceed our expectations.


At Obvious, we have an atypical hiring philosophy. We’re never hiring, but we always are. By doing this, we’ve not only ensured that we have small, tight teams that are capable of incredible work but also that we’re surrounded by people we love working with. 

If you think that you and Obvious might be a good fit for each other, apply here.

Read more

We simulated a hypertension clinic in our Bangalore office, and our team played the role of nurses, doctors, and patients. Everyone on the team learned how hard it is to juggle the different tasks in a busy clinic and we experienced how our software fits into a healthcare worker’s job.

Why create a simulation?

Our team is working on Simple, an Android app used by healthcare workers at public health facilities in India to manage patients with hypertension. To make our software a success, we must understand our users and the context in which they work.

Making software for clinical environments is really challenging. Workflows at hospitals and clinics are often chaotic. In a single visit, patients must visit many rooms in the hospital, like the outpatient registration desk, nurse’s room, doctor’s room, and the pharmacy. There are queues at each step. Nurses and doctors are under pressure and they’re asked to juggle many tasks at once. The Simple app is just one small part of their workload.

Of course, getting into the field and witnessing real patients being treated is a great method to understand our users. And, we do go into the field frequently to observe patient care. However, we wanted to find a way to give everyone on our team a deeper understanding of a healthcare worker’s job, firsthand.
It’s immensely valuable to play the role of a nurse or doctor yourself, which isn’t possible in a real clinic. So, we created a realistic simulation in our office to give everyone on our team the experience of being in the shoes of a busy healthcare worker treating a queue of “patients.” Engineers, designers, and project managers got to play each role in the clinic and now every one of us has a better understanding of how our software will be used in a real clinical context.

What did we do?

To create a successful simulation clinic:

1. Observe real users in the field

First, we observed clinical care at about 10 facilities in Punjab, India. Typical patient flows were mapped out. Nurses, doctors, pharmacists, and other healthcare workers were observed and interviewed. We took notes and took photos to better understand their environment and workflows. These learnings were used to recreate a typical workflow in our simulation clinic.

2. Identify the goals for role-playing

What do you want to learn and observe through the role-playing experience? Keep the goals brief and focused. Our goals were A) to learn what it is like to use our app as a nurse and as a doctor and B) to understand the challenges in typical workflows at a public health facility.

3. Make a plan for the clinic experience

Create roles and scenarios
Identify the roles and the scenarios to be included. Create a list of the tasks that these roles will perform. We created the primary roles of a nurse, a doctor, and a pharmacist. The pharmacist may also run the outpatient registration counter. We also created two secondary roles, a patient’s family member and a doctor’s assistant, to round out the scene.

Make the description of these roles clear and with just enough detail so that they serve as guidance to the team. For instance, we described the nurse’s role with the tasks that she performs when attending to hypertension patients and how she uses the various tools on her table.

See our plan for the simulation clinic…

A stack of patient IDs that we call “BP Passports”

Prepare relevant artifacts
We re-created nurses’ and pharmacists’ paper registers using our photos of the real registers used in clinics. We created prescription slips, bought a BP monitor, printed patient ID cards, and acquired medications. We printed the hypertension treatment protocol poster that contains crucial information for treating patients and put it on our simulation clinic’s wall.

Attending to details makes the environment feel realistic and believable. It gives the participant an immersive experience of what it’s like to juggle all of the tools and information required of a real nurse.

4. Set up the simulation clinic

We took several meeting rooms in our office and set up the nurse’s room, doctor’s room, and outpatient registration/pharmacy. Posters on the walls, similar to those seen in the field, were put up. The simulation clinic was large enough to simulate patient flows and patient queues, and small enough that the team was not too spread out so we could observe each others’ experiences.

Nurse’s desk — has a BP monitor, a stack of patient ID cards, a paper register to record newly registered hypertension patients, and a register to record all patient visits.

Outpatient registration counter and pharmacy with paper registers, medications and prescription slips.

5. Facilitate role-play

You will play the role of a facilitator — your main job will be to set the context and create an environment where your teammates can engage in a serious play-acting experience, learn about the users and find their own insights.

6. Gather your team together

Brief the team
The facilitator briefs the team about the plan for role-playing. Discuss the goals. Inform them that you will run two rounds of role-play followed by a debriefing session. Indicate the duration of each part of the plan.

Describe the roles
Describe the roles to the team. Have everyone pick roles that they want to play. Succinctly describe the scenarios that will be enacted. Printing out descriptions for easy reference for the team may be helpful. Here is an example of our roles.

Timebox the session
It really helps to set a relatively short timebox for each session. We wanted to give a sense of urgency for treating patients, so we limited the session to 30 minutes, which is about the time a doctor typically manages 5–6 patients (primary care doctors in India can see over 100 patients each day!).

7. Begin the role-playing sessions

The facilitator encourages team members to stay in the character of their roles, and helps ensure that the scenarios are being played out realistically.

Sometimes you may want to briefly step in as one of the actors to help tune up the realism of the scenarios. As a facilitator if you enact the roles realistically, your team members will be encouraged to do the same.

Mimicking observed disruptions to workflow is critical to ensure validity of the scenario. For instance, “patients” interrupting the “nurse” by asking her for some help or counseling is a typical situation that should be included. Interruptions require the “nurse” to switch context, respond to the “patient” in the moment, and then get back to the task that she was attending to.

Run at least two rounds of role-play. This ensures that the team members have the opportunity to play different roles, and allows enough time to make their observations. Create a brief quiet time after each session for everyone to individually write down their observations.

A ‘nurse’ attending to a ‘patient’

Queue of patients waiting to be attended to. Even in simulation, it is stressful to have a line of ‘patients’ waiting for treatment.

8. Debrief

Debriefing is a critical part of the process. Once the role-playing session is completed, now is the time for debriefing — to share what lessons were learned and identify the important action items.

Create time for individual reflection
Allow for enough time for individual reflection. We took 15 minutes where each person wrote out their learnings from the experience. We had a list of five questions that they could respond to while reflecting on the experience.

Try not to jump right into a group discussion — the loud voices will drown out others and people won’t have time to personally reflect. Quietly writing down experiences first helps each individual and will foster a more equitable and nuanced discussion afterwards.

Facilitate a rich and equitable discussion
We went around the table one-at-a-time and each person shared a key point they had learned. Go around the table several times.

Encourage people to discuss how they felt during the experience — what was frustrating, what was challenging, what was enjoyable, and what was motivating? This will help build empathy with your users and will lead to meaningful insights beyond usability challenges.

Identify the key takeaways
Identify the top 3–5 takeaways as a team. These are the most important learnings or action items. A key learning could be as simple as, ‘We learned that it’s really frustrating to be a patient and to get treatment at these clinics.’

One action item we came up with: Create a user manual that would guide nurses on how to correctly use the app. It was difficult to get started if you weren’t really familiar with the software.

Debriefing with the team at Obvious

What did we learn?

In just two hours, our entire team participated in the simulation clinic. We learned a few concrete things and gained an appreciation of the complex ballet in a clinic.

By role-playing and observing our colleagues, we learned that our app is one of several tools that a nurse or a doctor uses. It is very challenging to juggle all these tools, while simultaneously attending to a queue of anxious patients. We learned that we can’t assume users will give our software their full attention — everything must be easy to use and cause as little duplication of effort as possible.

We also observed how patient data moves between the nurse, the doctor and the pharmacist through the combination of prescription slips, patient ID cards, and the app. Points of potential breakdown were identified. We learnt about the challenges of navigating a public health clinic as a patient, and how that can lead to important patient data not being recorded correctly.

The simulated clinic afforded the safety to experience the difficult job of a healthcare worker. The experience gave us deepened empathy for clinicians and their patients. We all walked away with an impactful and long-lasting understanding of the context where our software is used that will help us to make better product and engineering decisions in the months ahead.

Any team that works on software will benefit from walking a mile in a user’s shoes. A simulation is one great way to bring that experience right into your office.



Thanks to everyone from Nilenso and Obvious who participated. Thanks to Akshay Verma for his help implementing the simulation clinic, and to Anand Rama Krishna for the photography.

Special thanks to Dr Terry CullenDr Greg Schmidt, and Erin Sykes for their help editing and to Daniel Burka for his help writing and editing.

Read more

Every second Saturday of the month, Obvious will hold a series of exclusive masterclasses to share skills and expertise with colleagues from both within the organisation as well as the larger design and engineering community. Each masterclass will be led by several members of the team on a range of topics and lead to a deeper understanding of how Obvious works to uphold its values of craft, context and community. You can find out more about the speakers, topics to be covered and a registration form over on our Talks and Events page. Since these events will strongly be focused on internal teams, we regret that seats may be limited.


Read more
The Obvious logo on a yellow background

We started Uncommon six years ago with a view to building beautiful, performant mobile applications. We were excited about the possibilities a powerful computer in everyone’s pocket allowed. Back when good design was yet to be recognised as ancillary to performance, we saw the possibilities that existed. We began with this vision: design for India and design for the future.


Like many other companies that started from a design-first approach, our clients often approached us as if we were interior decorators, whereas, a better analogy for the role we play is that of an architect. Rather than just picking out a new rug to tie a room together, we looked at the purpose that each space had, broke down some walls to allow people to flow from the kitchen to the dining room more easily, put in a modular shelving system to house a future book collection, and, in some cases, brought in a geologist to survey the bedrock that the house was built on.


Having worked with over 120+ clients, where others see dots, we see patterns. We have the advantage of…vantage. Of both having solved similar problems across different industries and having solved so many types of problems, that we’ve evolved a series of processes and ways of working that allow us to rapidly get up to speed on where our client’s problems lie, and what methods to follow to allow us to get to the right solution.


As technology becomes a necessity rather than a luxury, we hope to be the first port-of-call for any organisation that’s looking to use technology as a force-multiplier. Regardless of whether it’s an app-based startup, a paint manufacturer that’s looking at creating an internally-focused inventory management solution, or a massive consumer giant that’s looking to deliver a personalised experience for its customers, we believe that co-creating solutions with end-users, validation through prototyping and rapid iteration are the ways in which design can be channeled as a business-enabler.


We started our journey as a digital agency by setting ourselves up as an alternative to mainstream ways of thinking about software – we wanted to be, and were, uncommon. Over these years, we’ve now realised that we don’t want the processes that we follow or the ways in which we run our organisation to be limited to us – we don’t want these to be uncommon, we want these to be followed by everyone: we want to be more obvious.


We’re moving to a policy of public-by-default on all our processes, work and policies (check out our Playbook here). We’re making our work—and our ways of working—more obvious. We want our clients (and other designers, people who aren’t clients yet—anyone really) to take our ways of working and build on top of them. We will not come up with the obvious solutions but the solutions we do come up with will be obviously right.



As more of our work shifts to massive scale (into the hundreds of millions range from the tens of millions), design will need to be more obvious. It has to fit in with people’s lives, fit in with their contexts. Good design needs to be less uncommon, and far more present. It needs to be available. It needs to manifest less as the difference, and more as the default option.

Good design: it’s got to be Obvious.


Read more

I presented some work at Droidcon London 2018 on a particular problem I had solved using Android Path APIs nearly 2 years ago. Here I flesh out the problem and the steps that I took towards a solution. Project linked here.


I came across a problem on Stack Overflow in which an original poster wanted a custom progress view containing text within it. And this text needed to change its colour based on the background.




So when the background is orange, the text is white; when the background is white, the text needs to be orange. There is a similar problem related to underlying text by Romain Guy that introduced me to Path APIs for the very first time.


Why this particular problem?

I saw this problem posted in our local Android community Slack chat. I knew how to solve it thanks to Romain Guy’s article. I spent 3-4 hours building this animation where the color of the text changes based on the background. I finished the project, pushed it online, and made it open source here. I presented this solution to the original poster (OP) and it was exactly what they were looking for, and they were quite happy.

Tech behind the solution: Android Path APIs.

We started off with an introduction to set theory in order to help the audience understand the concept of operations that we applied to shapes, but in simpler terms using numbers. (The audience interaction was great fun ^_^ But we’ll skip that for now).

There are two parts to this:
— Left Hand Side (LHS): Curved rectangle with parts of text removed from it.
— Right Hand Side (RHS): Text with parts of curved rectangle removed from it.

Place LHS and RHS next to each other to create the complete animation.

When the seekbar position is updated, we update the width of the curved rectangle.










Place LHS and RHS next to each other and we get the full animation.













Conference Experience

My peers at Obvious were extremely supportive in helping me prepare for the talk. We had four rehearsals together. I did 20+ rehearsals on my own time to ensure the talk ran smoothly and the jokes landed!


I was very excited to take my first flight, and that it was an international flight to London. It was almost unbelievable, having pre-conference casual conversations in the party with Android developers I had followed for so many years. I met many cool Android devs working at Google, Facebook and other places. I got to speak to Android legends like Christina Lee, Jake Wharton, Stacy Devino and Florina Muntunescu. And of course, London was beautiful and extremely kind to me 🙂


The conference was huge and had thousands of people attending. There were 5 parallel talks all the time. I got to learn about interesting things in the Android world like Architecture Components, Android security, Coroutines and others.




London personal experiences

I had a good time on my own too! Cheese tasting, whiskey tasting, burgers, the Tower Bridge, Apple HQ, watching  The Play That Goes Wrong, pub-hopping with new friends, shopping and so much more!


Link to talk: http://uk.droidcon.com/skillscasts/12249-exploring-android-path-apis 


Read more

At Obvious, we spend considerable time doing user research in all forms and sizes. Here, I want to talk about how I optimized my workflow for usability tests to build realistic prototypes faster. I don’t want to get into the importance of user research and why is it essential to validate our assumptions. There are many great articles and books about this. I want to share my learnings while building prototypes under time pressure. I assume in this post that the readers have a basic understanding of Sketch and Invision.

Why build a prototype?

We run a lot of usability tests in our work, whether it is for a Design Sprint or our own research and conceptualization cycle that we call Relay. These user interviews are often an hour long and we test our product design with real users. In most cases, the product hasn’t been developed as yet, and we have to show them a simulated prototype, a very rough version that can be built and stitched together in a day or two, maximum. If this prototype mimics a real product closely, the findings from the users are richer. Building a realistic prototype in one or two days is crazy, there is no better word to describe it. I want to share my key learning on how I try to make it happen.

The ability to plan well is an underrated skill. If we do a good job, everything is smooth sailing. Only when trouble arises do we look over what went wrong in planning.


In order to plan ahead, we need to know all the constraints that we are working with.

  • How well is the prototype I am going to build fleshed out?
  • How much time do I need to spend on design details?
  • How many existing resources and guidelines can I use so that I don’t waste time creating assets?
  • How familiar am I with Sketch?


Pro tip: For our prototype, I try to use as many existing resources as possible—Screenshots, Libraries, anything that saves time for asset creation in Sketch.


In our engagements, we usually have two designers working on a project. Ideally, the person who is building the prototype should not be the one preparing and conducting the interview. However, if it is the case that only one person is at work, it’s important to keep in mind that this is a lot of work and requires a chunk of your time.


In my experience, it is always better to take smaller portions of work, something that I know can be finished on time. There will always be some unforeseen situation blocking you here and there, so it’s a great idea to have a sizeable buffer time. Since we want the best and clearest results, it is always better to present a smaller, better-crafted prototype to your users rather than a huge apparatus that tends to fall apart every other click. All small details matter, like naming consistencies, real data, spellings and so on.


This is what I consider a reasonable amount of clarity and planning for a prototype for one of our projects. This is, of course, after 3 days of a Design Sprint so we already had a lot of clarity on the goals and ideas to achieve them at this point.


Do whatever is possible in Sketch

Building all the screens is probably the chunk of the work. Unfortunately, not much speeds up this process other than using screenshots and existing libraries. Once I have finished building all screens and assets, I start stitching the prototype together in Sketch. This helps me save a lot of time. Linking Screens online in the InVision page can be tedious, so doing as much as possible offline speeds things up. Here is a great Tutorial on what all can be done and how.


Pro tip: If you have a long scroll, you can create a link to any place on the same page and InVision transitions the screen quite nicely.


With the craft plugin installed, you can link any layer to an artboard. Select a layer (i.e. your CTA), press ‘c’ and click on any artboard to establish a connection.


This way, I connect all screens that can be connected offline until my entire prototype is stitched together. This process can slow your computer down a tiny bit but is much faster than doing it online. In this approach, I don’t have to create hotspots and can use the actual layers in my sketch file. If I decide to move a button later, the link moves with it.


100+ Artboards and multiples of that in connections linked together in Sketch from one of the prototypes that I used in a user study


Sync with Craft

There isn’t much left of the glory that the Craft plugin used to bring into Sketch, but syncing your artboards still works and that is all that I am using it for at the moment. It’s still quite useful as long as you don’t change the names of your artboards: you can change them and update them online, hassle-free.

A small confession: while building a prototype under time pressure, I don’t care about naming artboards at all, so you might find 50 artboards in InVision called ‘something copy 56’. But as I said, as long as the names are consistent, it doesn’t matter. And since you don’t have to link, and hence, find artboards online, it doesn’t matter. But this is only because it is a one-time effort and we throw the prototypes out after we’re done.


Pro tip:If I have to add some special event online that I cannot create in Sketch, I actually leave a bright note on the artboard that I can find it easily in the InVision preview.


Leaving notes on an artboard that I know what to do online.


Once I made the change online, I can remove the note in Sketch and sync the artboard again. It’s a truly quick and dirty style of building, but my prototypes need to survive only for a day, and so I don’t care about scalability or maintainability.


Be careful with overlays

Having a popover or a menu expanding somewhere is often a part of an interactive prototype. The InVision overlay functionality promises more control over how something appears on top of a screen, like fading and transparent backgrounds. Having said which, I don’t think they work very well in InVision. They tend to break the prototype and are often the opposite of a smooth transition. I’d rather use a new screen and de-prioritise a fading transition to get a stable prototype. I would advise caution when using overlays.


InVision auto-events

Sometimes, I need to bring up an onboarding screen — Coach Marks or some sort of helper — if the user is unable to proceed on her own. For example, a pop-up should ideally appear after the user is unable to proceed for more than 15 seconds. Auto-events are great for creating that illusion. The interface for InVision is easy and straightforward. It’s pretty easy to set duration and a destination in Invision since you browse through your screens.


At the cost of being laughed at, I just want to mention what ms (milliseconds) are to avoid the confusion I had for some time. 1 second has 1000ms. If I want a screen to come up after 9 seconds, I have to set the duration to 9000ms.


You can also use auto-events to create very crude animations. I once used it to create a loader that had only three states (30, 65, and 100 % full). The three states are three screens with auto-events happening on them after ca. 300ms (for animation, see the following paragraph). It gave the illusion of something happening at the background of the prototype and made it more real for the user. Overall, auto-events are great and I recommend them highly.



The power of Gifs

Enter: Gimock Plugin.

Whether it is a loader or a small animation, moving objects make the prototype better and these little details go a long way. This plugin costs 14 USD and is definitely worth the money. Making loaders is incredibly easy and even complex animations can be made in minutes. You can use Gifmock’s built-in features or turn artboards into frames and export them as a GIF. InVision supports GIFs without any problem. The only downside is that you have to manually upload the GIFs outside your Sketch file. The same overrides work if you update your source file but keep the same name.

This is the main reason I continue to use InVision and not the prototyping tools in Sketch and Figma; as animations like these can make quite a difference!


This animation in the form of a GIF was made in just 10 minutes, but I believe it really made a difference to the user who had to learn and understand a new functionality


Real, real data

Using ‘Lorem Ipsum’ or other random data in a prototype is never a good idea. It makes the prototype appear less real. It appears even less real in prototypes that contain user profiles or other personalised information. We need a prototype to be as real as possible in every aspect.  On the evening before an interview, it should be clear which user is attending and the names of users should be accessible for the person organising and scheduling the testing sessions. While there might not be a lot of time, it should be possible to make use of this information. It can make a big difference to find your own name in an app or website and it helps to establish a connection to the product and provide better insights during the testing session. Using real data shifts the session from a hypothetical scenario to a real scenario and that is the expectation that a prototype should fulfil.


In this screen recording, a user is looking for public acknowledgement of the contribution she made to a story. She is positively surprised to find her actual name on that very page and starts explaining why public acknowledgement is important for contributors. This gave me valuable insight into developing the feature which wouldn’t have been the same if I hadn’t used her actual name.


Record it

I don’t like taking notes. Especially when I am the one conducting the interview. So, I use Silverback to capture all that matters: what happens on the screen, the mouse movement, the sound and the user’s expression. This way, I can listen and see what happened at a later point when I want to summarise my findings. Silverback has a free version, too, if you don’t mind the watermark on your export. These recordings then become my validation and proof for the client as well. In any case, it is a good idea to record user testing sessions

(Hint: Always ask for consent to record. I remind myself of this by making this the first point on the notes I prepare for the interview).

Silverback makes it very easy to record different users in a session and export them all at once. It captures a picture of the user as a thumbnail for the video. In my opinion, it is a great piece of software and incredible value for money.


Pro tip: Listen to your recording at a higher speed, you still get all the information. For me, the maximum that works well is 1.6x.


I am quite excited to see other prototyping tools develop and improve the process, and I love to learn how other designers or prototypers deal with these challenges. I hope this article is of use to people with profiles similar to mine. If you want to find out more about the work that we do, or just have a chat, send a mail to [email protected]

Read more

…and what we’re doing to build more diverse teams

We started Obvious six years ago and have since grown to a team of 20+ deeply-skilled craftspeople interested in design, technology, people and the intersection between these three. But there was a problem. Right from the get-go, our founding team was entirely male and between the ages of 25 and 30.


We know that we live and work in a world where certain groups are underrepresented in most spheres of work. In the design and technology space in India, most organisations are largely homogeneous entities with people whose experiences of life are by and large the same. Under representation is most visible in terms of gender, sexuality, disability and caste. We’ve been thinking about this, and about the ways in which we can change the status quo in our workplace.


We strongly believe that the strongest solutions (from technology and design perspectives) are made when a diversity of voices, opinions and perspectives are brought to bear on problems that our clients hire us to solve. We’ve learnt this from many (often disturbing) examples. Take for example ‘The Problem of the Abusive Ex’ —examples here and here. This is a prime example of what happens when technology solutions are designed primarily by people with a similar set of life experiences. There is also Inadvertent Algorithmic Cruelty, where even a well-intentioned product feature can lead to a situation of emotional distress for users (an idea from Eric Meyer who later wrote a book on the topic which you’re welcome to borrow from our library).


We need to be more diverse, not just because it makes business sense, but also because it makes us a better company. We’ve made some baby-steps towards a more inclusive work space. We wanted to share some of the progress we’ve made with you. If you’re from an underrepresented group, you can a) see what it might be like to work here, and b) exhort us to do better — we’re always open to suggestions and criticism. We try and do our best even though we work within the limits that exist for a small, self-funded company.


We’ve started work on changing our organisational DNA. Some of the things we have put in place are:


Paid Menstrual Leave

Following our compatriots Nilenso, we have adopted (read: wholesale stolen) a no-questions-asked menstrual leave policy.


Family health insurance which covers your spouse, and up to two children

While our health insurance is fairly comprehensive, we’re still trying to find a provider that covers domestic partners as well as mental health expenses.


Sane working hours, which allow for a life outside the office

Women all over the world work two jobs — one at the workplace, and another at home with household chores. We cannot change structural attitudes and practices that are deeply entrenched in society, of course, but we adhere to strict 40-hour working weeks. We do not penalise people who aren’t able to devote the entirety of their lives to writing code.


No late-evening events

The ability to travel safely and without hassle is heavily gendered. Transport for women is more expensive and far less safe. We try and ensure that our days end at consistent times. We don’t organise meetings and work events late in the evenings, taking care to ensure that nobody is excluded from valuable networking and career-building opportunities.


Paid Parental Leave

We were very pleased to discover that India has one of the more progressive maternity leave laws in the world. Mothers can take 26 weeks of leave after the birth of their child. We believe that fathers (and partners) should participate in the labour around…labour, and offer 12 weeks of paid paternity leave as well.


Clear policies on discrimination and sexual harassment, plus regular refresher workshops

Despite laws requiring all organisations in India with more than ten employees to set up a committee to address complaints about sexual harassment, implementation remains an uphill task. We have an independent committee whose decisions are mandatory to be accepted by management, backed by Parity Consulting, who serve as the external member on our ICC.

We make our clients aware that they are also covered by our prevention of sexual harassment guidelines, and build termination clauses into our contracts that would automatically trigger in the event of any reported sexual harassment.


Sponsoring community events (PyLadies and HasGeek)

If you’re running an event or a community that works with under-represented groups, you’re welcome to use our space (as PyLadies BLR has been). We work with HasGeek (an organisation we deeply respect) to build more diversity into their conferences. Their CEO, Zainab Bawa goes into more detail on their efforts here, here and here.

Many of us, including all three of our founders (Dhruv, Pratul and I) spend time meeting and mentoring people at the beginning of their careers. We try to make sure our time is available for people who are underrepresented.


Physical spaces
  • We’ve learnt from colleagues, friends and partners that work spaces often stigmatise menstruation. We know that something as simple as stocking menstrual supplies is not yet common sense. Learning from this, we make sure to stock necessary menstrual supplies in our bathrooms for free, and we hope this makes our workplace more welcoming.
  • Everyone comes in different shapes and sizes. We’ve put in considerable effort and expense to ensure that everyone in the office has ergonomic, height-adjustable furniture, allowing for a workspace which everyone can adapt to themselves.
  • We were not surprised to find that office temperatures are benchmarked against the metabolic rates of an average (wait for it) man, leading to uncomfortable working conditions for most female employees. An awareness of these gendered biases which have been codified into “standards” allows us to avoid them, and helps us create an office space which is more productive.


Which brings us back to what we wanted to talk about: if this is a workplace where you would like to be, please do write in. We’re looking for product designers, researchers, illustrators and developers for mobile devices and the web.

We do interesting work, with almost all the household name startups in India. This year, nearly 60% of our work will be openly-licensed (we’ll write about our open-source work soon on our website). We care deeply about our craft and the context in which our work will be used. Our work reaches hundreds of millions of people every month, and we sweat the details.

Write in to me, send me a DM on twitter, or drop by into our sunny Central Bangalore office. We’d love to work together.


Read more

I’ve been more or less mute for the last four weeks because I somehow managed to get an injury inside my throat. Not being able to talk means going out and meeting people is not much fun (wonder what that says about me), so I’ve been spending a lot of time tinkering at home.


… and some days I just do this


I’ve been curious for a while about how much impact merely including a JavaScript framework has on the performance of a web page. I started thinking about this a few months ago, when I spent a rather frustrating afternoon trying to improve the parse and evaluation time of a JavaScript bundle on a cheap phone, only to find that most of the bundle’s size was taken up by React and its associated libraries.


Truth is, when you build your application on top of a modern JavaScript framework, you agree to pay a certain baseline performance cost that can never be optimized away. In exchange for paying this cost, you gain maintainability, developer efficiency, and (hopefully) better performance during runtime.


Well, duh. You didn’t need me to tell you that.



However, let’s phrase this differently: when you build your app on top of a JavaScript framework, you’re making peace with the fact that your app will never load in less than X seconds, for some value of X that varies from framework to framework.


So what exactly is this baseline performance cost, this X? Glad you asked! I had a free afternoon and a Redmi 6A lying around, so I ran some numbers using React, Vue, and Angular.



Here’s how I arrived at the benchmark results you’ll see below:

  1. Initialized new React, Vue, and Angular projects using create-react-app, Vue CLI, and Angular CLI. I didn’t make any changes to the projects generated by these tools.
  2. Installed routing and data management libraries in each project, and made sure they were part of the JavaScript bundle.
  3. Deployed all three projects to Netlify. Here are the pages: React, VueAngular.
  4. Connected a Xiaomi Redmi 6A to my computer and ran a profile on all three pages using the Chrome DevTools.


The routing and data management libraries I used for each project were: react-router and redux for React, vue-router and vuex for Vue, and the built-in Angular router and ngrx for Angular.


When I ran my benchmarks, I was interested in two numbers:

  1. The time taken to download all the JavaScript required to render the page. I only took the content download time into account, and ignored the network latency, the time required to setup an SSL connection, etc. because I don’t have as much control over these factors as my bundle size.
  2. Time taken to parse, compile, and evaluate the JavaScript bundle

I should mention that the Redmi 6A is a pretty new device, and most Indian users are still using the older Redmi 5A with a slower CPU.


The Numbers

Here are the numbers, starting with the bundle sizes for each application.


Gzipped bundle sizes for all three frameworks plus their routing and data management libraries


Angular’s JavaScript bundle is about twice large as the bundles for Vue and React! My guess is that this is because Angular has a much larger API surface and ships with the entirety of RxJS. I’m hoping somebody more familiar with Angular can enlighten me here.


Time requires to parse and evaluate the JavaScript bundle for each framework


While it takes a respectable 200 milliseconds for Chrome to parse and evaluate the React and Vue bundles, it takes over half a second to evaluate the Angular bundle. That’s a large enough interval for your users to notice, and can really cut into your performance budget.


Content download time, without taking network latency and other factors into account


Unsurprisingly, the React and Vue bundles are downloaded in under a second, but the Angular bundle takes over 2 seconds to download.

What’s important here is not how large or small the numbers are, or the relative performance of the three frameworks compared to each other. What’s noteworthy is the fact that your React application will never load faster than about 1.1 seconds on an average phone in India, no matter how much you optimize it. Your Angular app will always take at least 2.7 seconds to boot up. The users of your Vue app will need to wait at least 1 second before they can start using it.


This is when we haven’t even started looking at some of the other essential libraries that most projects end up using. This includes polyfills, form management libraries, date and time libraries, utility libraries such as lodash, drag and drop libraries, charting libraries, etc.



If you want your application to become interactive on your users’ devices in under 5 seconds, can you afford to spend a fifth of that time just booting up React?


Are Frameworks Evil?

I’m not advocating that frameworks are evil, or that you should write all your applications in VanillaJS. That would waste far too much productive developer time, and the result will probably end up performing badly at runtime. Frameworks exist for a reason.


But it’s important to consider your audience. If you’re building for resource constrained devices — which you certainly are if your product targets a country like India — you could consider using a lighter framework such as Riot or Preact. Your users will thank you.


Or consider not using a framework at all. For websites that primarily display content, it’s more efficient and cost-effective to just send some server-rendered HTML down the wire. If there are areas of your website that require interactivity, you can always use JavaScript to build those specific parts.


In the end, it’s important to strike a balance between developer productivity and user experience. The answer will vary from project to project, so don’t take anyone’s advice as gospel. Build for your own audience, not somebody else’s. Run benchmarks on devices that represent real-world scenarios, and then decide what technologies make sense for you.

Read more

Every aspect of Obvious is an opportunity to apply design thinking to situations and our infrastructure is no exception: we live on the internet —and therefore, our internet should always be alive. When it was time to redo our office network, the question I asked myself was: can it be a pleasure to set up, manage, and derive insights from something as mundane as our network connection?

I have deep doubts and misgivings about WiFi (reasons in detail here), so one of the key requirements that I gave our architects when we were renovating our office was that every desk should have an ethernet port, directly connected to our network backbone for full-duplex, gigabit internet access at every workstation. One post which I kept going back to while designing our office was Joel Spolsky’s “Bionic Office” (from 2003!):

Every office has its own 8-port network switch, so you can plug in your laptop and your desktop and your Macintosh and that old computer you keep around to read Joel on Software when your main computer is rebooting to install today’s Windows Update, and still have 3 ports left over (attention math geniuses: no need to email. One port is the uplink.) I sneer at silly building managers who still think that one LAN port per office is about right. For lawyers, maybe.

However, in addition to dedicated ethernet ports, we also need to have excellent WiFi — as our work and our devices are far more mobile than when Joel wrote about the Bionic Office.

Enter Ubiquiti

It was unsurprising to find that Ubiquti was founded by an ex-Apple engineer. Their products are elegantly plain, mostly white and glow gently, a-la the old Macbook breathing LEDs (which I miss sorely). Their wireless access points blend into the surroundings, unlike “high-end” consumer routers (Exhibits A, B, C and oh dear god what).

Unifi’s Wireless Access Points even have “skins” to match their surroundings

Ubiquiti (and other semi-professional networking equipment) separate out routing, switching and WiFi access into separate devices which perform one function well. Our internet comes into their router — the Unifi Security Gateway Pro, which supports multiple ISPs for failover and load-balancing.

Our router

The next piece of equipment is our core network switch — a managed switch with power-over-ethernet. This powers a bunch of smaller devices, including our network controller, a RIPE Atlas probe (courtesy @louiswu) and potentially thin clients or IP cameras in the future.

Any port in a storm

The cool thing about a PoE-switch is that the wireless access points don’t require a separate power cable, and draw their power right off the network cable. This really simplifies where you can place them — you don’t require a power outlet to set up an access point. We have two AC Pro routers, which are probably overkill for the amount of space that we have.


Enough about the hardware — the coolest part about Ubiquti is what they call “software-defined-networking”. Their control interface is fantastically cool — and looks something like this:

The Unifi Dashboard
Speed tests (L) and Network Topology (R)
Live coverage maps (L) and detailed port statistics (R)

I can easily spot issues with either our network traffic, see if there are particular access points which are overloaded, upgrade firmware on all the network connected devices — it even has an extremely well-designed mobile app, which you can use to login to all your networks from anywhere in the world, and perform fixes, diagnose problems, all the sys-admin-y tasks that you would usually have to be on the same network to perform.


Don’t buy any Ubiquiti gear off Amazon/Flipkart. Prices there are highly inflated. Look at Ubiquiti’s prices on their US website, and don’t pay more than 5–10% extra. We’ve had good results with the following dealers:

To redo your home network, all you probably need is an access point (or two). You can run their controller on any computer, and can reuse your existing router. You can then add to your network iteratively, adding in the Security Gateway or a managed switch over time.

Alternatively, for an even simpler approach, where you sacrifice some configuration ability, look at their Amplifi range. This is a mesh system, with beautifully designed hardware.

Pretty fly for a WiFi…

We accomplished all our goals with this network gear:

  1. Fast and reliable internet across our entire office
  2. Easy to set up failover, load-balancing and scales to hundreds of users
  3. Simple enough for a non-technical person like myself to set up and run
  4. Isolated guest networks with simple login, bandwidth restrictions
  5. Passes the critical Designer Test: looks and works elegantly

It looks like we’re also in good company:


The only unfortunate part of this entire story is that now having seen how elegant and stable this network is, I am undertaking an expensive exercise to replace all the routers and access points both at home and at my parents with this gear.

Read more