The What

Feedback conversations are a chance to give your colleagues healthy, honest feedback about their work or interactions. When done properly, they offer an opportunity for regular, consistent growth as well as a chance to establish deep, credible relationships. These short conversations, let you show your team members you care by offering constructive criticism or praise.

The Why

The only way to help your team improve is by telling them what they are doing correctly and how they can do more of it. Or, by telling them what they are doing that is ineffective and how they can avoid or do less of it.

People often save this kind of feedback for one-on-ones, which does not help because the context is lost or it is too late to do anything about. It is important to provide praise or criticism as close to the event as possible. Holding back comments causes resentment to build up that often comes to a boiling point and explodes. Also, it’s nice to compliment team members. At Obvious, constructive feedback is a way of life!

Use the following four steps to ensure that feedback is both objective and constructive.

Step 1: Ask & Listen

Before providing feedback, verify that your understanding of the situation is correct by asking a question or two about what they were trying to accomplish. This ensures that the feedback is offered in the right context and that the person on the receiving end does not feel misunderstood. To do this effectively, use the Situation -> Behaviour -> Impact (SBI) model.

Example: When we met with the client this morning and she asked how our team would decide how we find candidates for the user studies (situation), you told her that we will not discuss that today and that it was not relevant to the conversation (behaviour). She stopped participating and cut short our proposal meeting (impact). She wanted a better understanding of our process, and she felt that her questions were not considered important. I would love to hear your take on the situation.

Now that you confirmed your evaluation, it’s time to let the other person talk. Genuinely listen to what they have to say.

Try the following tips to be successful in this step –

Focus on the Situation

When seeking clarification, ask unemotional and non-judgemental questions. They should be about the work or idea, not about the person, and stick to the facts. Find out what they were trying to accomplish.

Focus on Listening

Talk less, listen more. Instead of thinking of a rebuttal when someone else presents their idea, actively listen to the speaker. Give your colleague time to think and answer. Try being comfortable with pockets of silence; they often help create a safe space for the speaker.

Step 2: Guide

Once the context has been established and the other person has presented their take on the situation, now is the time to provide feedback. Think of guidance as a tool that helps, not a whip or a carrot. Offer genuine advice on how to continue the behaviour or make it better.

Try the following tips to be successful in this step –

Default to Good Faith

When providing constructive criticism, trust that the person receiving it tried their best. If you receive feedback, believe that the person giving it is trying to help you.

Criticize in Private, Praise in Public

Deliver critical feedback privately. Criticism can lose its constructive power when done publicly because some people become defensive, escalating the situation. On the other hand, appreciation gains exponential leverage when offered in public.

Start with Genuine Praise

Obvious is filled with smart people, and we can all learn something from each other. Nearly every situation has positive aspects, so start there. Beginning a conversation with praise opens people up for receiving criticism, but ensure that your comments are genuine because people will see through it.

Use Radical Candor

Radical Candor is a fantastic framework for providing honest and constructive feedback to colleagues. We recommend that you read the book or listen to the podcast. The framework relies on this simple idea: In order to provide clear and candid feedback to your colleagues that challenges them directly, you must first establish a deep sense of trust and show them that you care about them personally.

One-on-one meetings offer a solid opportunity to go up on the “Care Personally” axis with your colleagues. Once that is achieved, it’s easy to provide candid feedback because it helps people open up to being “Challenged Directly”.

Step 3: Discuss

After providing feedback, there is likely to be a discussion. For praise, the conversation will probably go smoothly and may simply be a “thank you”. Regarding constructive criticism, it is important to give the person time to absorb the information and ask for further clarification. Answer their questions with facts, not emotions.

Try the following tips to be successful in this step –

Be Mindful of Your Words

No matter how hard you try to depersonalise the feedback, it is personal for the person receiving it. Telling someone to “not take it personally” is similar to telling someone “not to be sad”. Using the words “works/doesn’t work” instead of “like/dislike” keeps the conversation focused on facts.

Distance Yourself From Your Work

If you’re the one receiving criticism, genuinely listen to the advice. Distance yourself from your work and critique yourself objectively. If you find fault in what you’ve done, then you can improve it. Receiving criticism without letting it hurt you is a true skill that takes practice.

Provide Direction, not Navigation

Telling people what to do, doesn’t work. Nobody likes to be told what to do. When giving feedback, only provide direction, not step-by-step navigation.

Play “Yes and…”

The premise of this common improv technique is to accept an idea as true and build on it. The goal is to refine ideas and gain clarity. Reserve judgement of others’ suggestions until you fully explore them. For example:

Person 1: I know this might sound crazy because we have an upcoming deadline, but running another user study before we make a final decision might provide the clarity we need.

Person 2: Yes, and then we can be sure that this feature is relevant for our users. Let’s talk to the product manager about pushing the deadline out a few days.

Step 4: Resolve

After a short but healthy discussion, the feedback could be complete, or you may decide to continue the conversation later. If you defer, set a clear time and commit to it. No matter how the conversation ends, leave on good terms. A simple “Thanks for listening!” goes a long way.

Try the following tips to be successful in this step –

Time Box

These informal feedback conversations should be relatively short. If the discussion becomes heated or lengthy, it’s best to postpone the talks and discuss it later.

Follow Up

If you deferred the discussion, don’t spend time trying to bolster your case. Go into the meeting to listen and clarify.

If you’re looking to work in a company that invests in you, you should know we’re always hiring. 

We’re looking for engineers, designers and researchers across all levels and would love for you to join the team.

Read more
The What

Team conversations provide an opportunity to reflect on the previous week’s work, share important updates, and discuss and debate decisions that may need course correction. These conversations also create alignment between team members and set the direction for internal and external projects for the upcoming week.

The Why

Communication is vital to every project, so it is important that we dedicate time to bring the team together. When everyone is aligned, projects run smoother and more efficiently and lead to exceptional products. Team Conversations confirm that the team has a common direction, and everyone’s efforts are geared towards the same larger goal. We recommend the use of the following framework to run team conversations effectively.

Step 1: Reflect

Recommended time: 20 minutes

At the beginning of the meeting, team members update the project board with short snippets of what happened last week. Everyone then reviews their colleagues’ reflections in the context of the project plan and key metrics, quickly making notes, and the discussion begins:

  • What went well last week? How can we do even better this week?

  • What did not go well last week? How can we make improvements this week?

Step 2: Update and Clarify

Recommended time: 20 minutes

Next, team members look at what is planned for the upcoming week. They update the project board with new tasks and remove redundant ones. They also add comments about issues that might directly or indirectly impact the project.

Direct Impact: “We need to run a user study to test an idea that we’re not confident about. This will require 3 additional days that had not been previously planned”.

Indirect Impact: “I will be out for a week because of a family emergency. I will be working, but available intermittently”.

Everyone takes a minute or two to ask questions and seek quick clarification on updates that are not obvious. The team votes on which updates to discuss further. The topics should be ones that need the alignment of the entire team. Anything that can be resolved without everyone’s involvement should be handled outside this meeting.

Step 3: Brainstorm

Recommended time: 30 to 60 minutes

The available time for brainstorming is divided into smaller periods according to the issues that need ideation. If the length is inadequate, the number of topics is reduced through a quick round of voting.

The team brainstorms on the topics so that everyone is aligned on the new ideas for the upcoming week. While it is difficult to completely solve every problem in a short brainstorming session, the goal is to set a direction for each topic. Deeper brainstorming can happen later between those directly responsible for each task.

Step 4: Plan

Recommended time: 20 minutes

Using inputs from the brainstorming activity, the plan for the upcoming week is adjusted. The discussion creates a rough estimate of how long it might take to accomplish the new tasks and how much can be completed before the next iteration begins. From this, the team has prioritised tasks with estimations. The project lead ensures that the plan is pragmatic, achievable and aligns with the team and business goals.


Use the following tips to make the most of your Team Conversations.

Keep Egos Out

Leave your ego outside the Team Conversation. Using the words “works/doesn’t work” instead of “like/dislike” keeps the conversation focused on facts instead of making it personal. Our team is united by the goal of creating the best solution for the end user. It’s not about one person’s idea winning or losing.

Focus on Quiet Listening

Talk less, listen more. Instead of thinking of a rebuttal when someone else presents their idea, actively listen to the speaker. Ask for clarification to fully understand the concept, and then listen intently. Paraphrase a team member if you disagree to ensure that you have an accurate understanding of their viewpoint.

Play “Yes and…”

The premise of this common improv technique is to accept an idea as true and build on it. The goal is to refine ideas and gain clarity. Reserve judgement of others’ suggestions until you fully explore them. For example:

Person 1: I know this might sound crazy because we have an upcoming deadline, but running another user study before we make a final decision might provide the clarity we need.

Person 2: Yes, and then we can be sure that this feature is relevant for our users. Let’s talk to the product manager about pushing the deadline out a few days.

Time Box

Cap each discussion by setting time limits in advance. If a decision is not reached, decide whether to continue the conversation later or vote to resolve the disagreement. Consider using a Time Timer so that everyone stays on track.

Make Evidence-Based Decisions

At Obvious, we make decisions based on evidence, not gut feelings. If your argument lacks evidence, we ask you to let it go and trust your colleagues’ idea.

We also try to reach a unanimous agreement with decisions, but that scenario is not always possible. Ultimately, someone has to decide, and that person is the Decision Maker. When the Decision Maker has to step in, feel free to disagree, but commit to the decision.

If you’re looking to work in a company that invests in you, you should know we’re always hiring. 

We’re looking for engineers, designers and researchers across all levels and would love for you to join the team.

Read more

We’ve been lucky with workspaces. Our first office was a beautiful, 100-year old building, crumbling at the edges. The rain would come in and monkeys would steal your lunch. Our next two offices were equally quintessential Bangalore – one just next to a sleepy railway station, and the other nestled off MG Road amidst the greenery that the city was once known for.


We built out our last office to accommodate  around 12 people. We were still there at 25, with people sharing desks, the dining area repurposed into a work space, and the triple-height lounge crammed with tables. It was time to move.

My role within Obvious has changed significantly over the last few years, from doing hands-on design work to growing a business. While I enjoy the challenges and the learnings that come as part of organisational building, I was extremely excited about diving back into design thinking, and applying it to physical space. Working with architect Elayaraja Mayavan and his team, I set out to build a workplace that we’d want to spend most of our day in.

The Plan

Community and Ritual

We oriented the office along a public-private axis – with a full half of the office reserved for what we think of as our Community space. It’s a large, almost cafe-style space, with massive amounts of light. It’s where we all gather to eat lunch together (one of the favourite parts of my day), we hold an irregular movie evening, and we’ve already hosted several talks and workshops where we’ve had upwards of 50 or 60 people join us.


Collaboration and Craft

As you move into the quieter, focused part of our office, there are a variety of work spaces that accomodate different work modes. We’ve got more open spaces, where teams can whiteboard together, large private rooms to run workshops (like our Design Sprints), as well as a large, library-silent space that allows everyone who wants to do focused work a place where they know they won’t be disturbed in. We even snuck a little audio/video-editing studio, and my favourite part – a light-drenched reading nook, that holds our (growing) library and large couches for those post-lunch power naps.


It was almost a given that I was going to be an architecture queen: the fact that I own the entire back-catalogue of Grand Designs is perhaps a leading indicator. Whether it was insisting that we use no colour apart from white (right down to our clocks), inspecting every sheet of birch ply to see whether the grain and variations matched, or spending hours on finding the perfect soft-finish cement epoxy for our floor, I probably spent a little bit too much time sweating the details. I drove our architects quite mad, making them redo the lighting several times and being rather indecisive about the shape of our air conditioning vents. I’d like to believe though, that this all contributed to a space that feels intentional.

Ergonomics: if you’re going to be in front of a computer for eight hours a day, make sure it’s set up for you. Everyone at Obvious gets sit-stand, height-adjustable desks plus massive monitors and mechanical keyboards, so that we can keep off injuries related to ergonomics.


Local Designers: where we splurged was in supporting local designers and craftspeople – we bought an original Sandeep Sangaru couch (“The Ring”) and some very nice, minimalist chairs from Spin.

Bathrooms: We reversed the colour scheme from bright and white – making them dramatically lit, dark and intimate spaces.

Plants: all of our balconies (and we have a lot of them), have themed plants–one is around colour, one around smell etc. We’ve chosen indoor plants which act as natural air purifiers.

The Future of Obvious

In every other aspect of our company – whether it’s hiring, whether it’s what our team looks like, whether it’s paying people doing the same work the same , we’re trying to reimagine how a group of people can come together and build things that are so radically better that these practices just become…obvious…to the rest of the world. I think that our physical environment is no different – it’s a part of how we take care of each other, and hopefully, a place to be inspired, everyday.

Read more

By Sasikanth Miriyampalli


You may be wondering, “why not use production code in tests?” Sometimes it might not be possible — like calling an Android framework class in unit tests — or sometimes we don’t want to. For example, if we want to test out a retrofit network call that transfers money from one account to another, we don’t want to transfer money every time the test is called. In those cases we replace the production code with alternative implementations for testing purposes and these are called ‘Test Doubles.’

There are various types of test doubles; in this article, we will take a look at 3 commonly used ones: FakesMocks, and Stubs.

Examples listed in this article are written in Kotlin, but the concepts are transferable. While it is possible to use our own implementation for providing the mocking and stubbing logic, in this article we’ll be using a mocking framework called mockito-kotlin to make generating test doubles easy.


Fakes have working implementation but have alternative code compared to the production; sometimes it might be much simpler compared to production code.

An example for this case is using a fake datasource instead of touching the actual database or network or performing disk operations. In the following example we are making a FakeContactsDao that can be used to replace the production version in tests. This implementation is simpler compared to the production version which would have to deal with database. This is especially useful in instrumented/integration tests where you might be testing the entire implementation of the datasource.


Mocks are objects that expect certain calls to be made. They will throw an assertion error when they don’t receive those calls that are expected or if they receive a call that is not expected.

We use mocks when we don’t want to invoke the production code but want to check if the action is called or check how many times a certain action is performed. This is especially useful when you cannot run the production code in tests or if you want to avoid running the production code in tests but still verify that the methods are invoked.

In the following example we have a UserPaymentsRepo that takes in PaymentsApi . When we send a payment to the user, we expect to call the PaymentsApi#payUser.

We verify that method is invoked and no other method from the PaymentsApi is called.


Stubs are objects that lets you control a methods behaviour in a test. They are usually placed at the top of the test.

An example for this case is returning predefined data whenever a database method is called. We are doing this to avoid calling the database in tests or testing various database cases.

Let’s say we are making a social networking app and we want to get list of starred contacts for the user.

Instead of making the database call, we provide a stub that returns a predefined list of starred contacts. Then we can assert that we received the same contacts when we are calling userViewModel.starredContacts

When to use

Here is how I decide when to use Fakes, Stubs, Mocks.

Fakes – To provide alternate implementation of the production code that is independent of the system and can be tested quickly.
Mocks – To mock the production code and also to verify all the actions are performed/not to be performed in the test case.
Stubs – To have a predefined response for the calls made during the test case.

Reading notes

TestDouble – Martin Fowler
Mocks Aren’t Stubs – Martin Fowler
Introduction to Test Doubles and Dependency Injection – Google Codelabs
Fundamentals of Testing – Android Developers

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

Dedicated time with your manager, focused on what’s important to you.

The What

One-on-one meetings are an opportunity for you to meet with your manager and discuss anything you want, in private. This is your time! You set the agenda, format, and location. During this time, you can give feedback, build and enhance trust with your manager, discuss new ideas and problems, and brainstorm on ways to advance your career. We specifically devote this time to you.

The Why

At Obvious, our goal is to create an environment where everyone feels empowered, supported, and heard. To accomplish this objective, we must create a safe setting for you to discuss your ambitions, concerns, and suggestions. One-on-ones provide you with that opportunity


You, as the direct report, decide the agenda of your one-on-one with your manager. You create a format that works best for you, and it may change each time, depending on your priorities. We recommend focusing on topics that pertain only to you. In other words, things you are not ready to discuss in front of the entire team.

We suggest covering: positive work events, negative work events, manager feedback and outside life. Each one-on-one, though, does not need to cover all four areas. These proposed topics provide general guidance, but you have ultimate control.

Outside Life

We do not want to pry into your personal life, but sometimes, it is beneficial to share what goes on in your life outside of work. Perhaps you’re going through something personally that causes you to be distracted, or have a health issue that sometimes requires you to be away from work during normal business hours. Speak as freely as you want and know that your information will always remain confidential.

In addition, it is helpful for managers to know what motivates you. If your life’s goal is to open a design school, let’s talk about the skills necessary for that to become a reality and how we can develop those while you are at Obvious. We understand that people’s aspirations change. You may not want to be in your current job forever. If you want to do something else in life, we want to support you and see you succeed in that goal.

One-on-ones are the time for you to speak about whatever you want. Each meeting may focus on a different topic or could be a continuation of a previous conversation. You call the shots!

Positive Work Events

Discussing what drives you shows your manager what you enjoy and want to do. By conveying this information, it makes it easier for your manager to provide you with more of those opportunities.


What motivates you to come to work? When you are excited to come into the office, then you are likely to be more productive, and that energy is contagious. We want to do what we can to keep you motivated, so let us know what that is.

New Ideas

New ideas are like infants – innocent and fragile. They need care and nurturing before they stand on their own. Use this time to explain any new ideas you have, then brainstorm and ask for constructive guidance before rolling it out on a larger scale. These ideas could be small items like a new type of coffee, or larger suggestions such as a new way to work with a client. Creativity is crucial at Obvious, so use this time to strengthen your ideas at their inception.


Share your aspirations and areas where you are trying to improve and ask for guidance on what you can do to move in their direction. This discussion will not replace the bi-yearly Career Conversations or day-to-day feedback, but rather, it may serve as a midpoint check-in to ensure progress regarding your path.

Negative Work Events

We spend a lot of time at work, so let’s make the experience a pleasant one. To do that, your manager also needs to know what is not working for you. While we do not want these meetings to turn into gripe sessions, vent your frustrations and together we will find a solution.


What do you dread about coming into work? Let your manager know what that is. Odds are we can resolve the issue. Come with possible solutions, but we can brainstorm together.


If you experience roadblocks that impede doing your job or make you feel unproductive, let us know. We will look for answers or workarounds. It may take a few attempts, but we will continue to address the problem.


Bring up things that are in the back of your mind. Maybe you do not know exactly what it is, but you know something isn’t quite right or could be improved. Be as honest as you can. Or perhaps, you need extra support or advice.

Feedback for the Manager

Hopefully, you already provide your manager with immediate, personal one-on-one feedback regularly, whether after a meeting, privately, or through written communication. However, sometimes you might need more time. Use these meetings to give advice on how your manager can impact you directly. Also, use this time to follow up on previous advice you gave your manager to let them know how it is going.

We recommend using the Situation → Behaviour → Impact (SBI) model. Tell your manager what impact, both positive and negative, their behaviour had on you in the context of a particular situation.

What can the manager do more of?

What can your manager do to make you more productive and happy? When possible, use the SBI model and be as specific as you can.

What can the manager do less of?

Tell your manager what they could stop doing to make your job easier. Remember to use the SBI model and avoid talking about the personality of your manager.


Use the following tips to make the most of your one-on-ones:


Use one-on-ones as a time to release the pressure you might be under. We want these meetings to be collaborative and relaxed not something dreaded. Look at it as a time to reset yourself. So, choose a format that puts you at ease, such as having coffee or tea, taking a walk or going to lunch.


These meetings occur once a month for 60 minutes and are scheduled at roughly the same time. The one-on-ones can be rescheduled when necessary but not cancelled.

Resist Work Critique

We encourage specific feedback using the SBI model to occur in three to five-minute conversations right after the situation instead of in the one-on-ones. Instead of saving up that feedback, deliver it when it has the most impact.

Keep a List

Instead of preparing a list of things to talk about at the last minute, keep an on-going list. This could be a separate list from the one you share with your manager or not. When a thought pops into your head during the week, add it immediately instead of trying to remember it.

Shared Feedback Document

Keep a written account of your meetings so that you can look back and see progress. Share the document with your manager where s/he can make comments and track your growth. Either take notes during your one-on-one or add notes after the meeting. In addition, add notes throughout the week. This master list of your yearly progress will be helpful when the Career Conversation comes around!

Bullshit Meter

As in everything we do, it is important to measure how well the one-on-ones are working. The following are indications that the process is not going smoothly.

Only Good News

If you only talk about how positive everything is and how well you are doing, you limit the feedback your manager can provide. Bring issues up as soon as possible so that the two of you can plan a course of action.

Lack of Criticism for the Manager

Praise is great but constructive criticism and suggestions are crucial as well. It is how we grow as individuals and as a team. Managers make mistakes and want to know when it happens. In fact, we encourage it. If you feel uncomfortable critiquing, then talk it through at these one-on-ones.

No Agenda

While we encourage free-flowing meetings, the direct report, who sets the agenda, needs to have a general idea of what to talk about. We specifically carve out time for these meetings because we feel strongly that they will increase the effectiveness of everyone involved, on a personal and professional level.


If you have the same conversation with your manager month after month with no progress, then something is wrong. Use the guidance in this document and to mix it up a little bit.

Notes and Definitions

Situation → Behaviour → Impact Model

The best way to provide constructive feedback, both positive and negative, is by putting your comments in context instead of being vague. For maximum effect, state the situation, the behaviour you liked/disliked, and how it impacted you. We call this the SBI model. Use it to offer sincere praise, or seek clarification before delivering critical feedback. Let’s look at two examples:

Positive Feedback

Vague: You did an excellent job with that client this morning!

SBI: During the meeting this morning when the client suggested changing the home-screen (situation), the approach you took to walk him through how the modifications would negatively affect users (behaviour) saved us from creating a poor user experience and also helped him understand how important it is to keep users in mind at all times (impact). Thanks for taking the time to walk him through it.

Negative Feedback

Vague: That client will never hire us thanks to you!

SBI: When we met with the client this morning and she asked how our team would decide how we find candidates for the user studies (situation), you told her that we will not discuss that today and that it was not relevant to the conversation (behaviour). She stopped participating and cut short our proposal meeting (impact). She wanted a better understanding of our process, and she felt that her questions were not considered important. I would love to hear your take on the situation.

In both these conversations, the SBI approach provides the one receiving the feedback with concrete information that allows them to either change their behaviour in the future or receive the compliment knowing that it is sincere.

Read more

Achieving professional dreams, large and small, through clarity and mindful planning.


The What

Career conversations help individuals gain clarity about their professional lives as well as how that plays into their personal goals. These conversations occur every 6 months, starting 6 months after employment. Each conversation takes about 2 hours and focuses on the person’s growth trajectory by developing a custom-tailored growth plan based on their medium and long-term aspirations.

The Why

People choose different career paths and have varying professional goals. While some people seek constant growth and more responsibility, others want stability and time to master some skills. An overarching career framework helps, but it is not enough to ensure everyone’s success. While it is a good first step that presents general guidance and direction, we must supplement that by providing each individual clarity on how to achieve their specific goals by developing a personalised growth plan. Career conversations help managers understand the values, dreams and professional aspirations of their direct reports, which further helps create the right opportunities.

Here is how we conduct career conversations at Obvious: 

Step 1: Value System

Recommended time: 30 – 45 minutes

To offer an individual enjoyment and satisfaction at work, it is imperative that the organisation supports the person’s value system. Values are different than goals. In fact, values are what remain intact when goals change. They are what one practices daily without expecting short-term results. For instance, honesty, safety, and teamwork are examples of personal values.

To understand a person’s value system, you must first understand the individual. One-on-one conversations offer a solid opportunity to know your direct report’s personal life story, slowly building a rapport over time. Depending on how well you know your direct report, you may only spend a few minutes recapping your understanding and offering them a chance to tell you more. Or, you might concentrate on learning more about them, especially if they are new.

Once you break ground in knowing your direct report better, use that information to incorporate their value system into their personalised growth plan. For example, a person who enjoys playing team sports might have effective teamwork as a core value. So, part of their growth plan should ensure that they work on projects with collaborative teamwork instead of projects that rely heavily on deep individual contribution.

Step 2: Aspirations

Recommended time: 30 – 45 minutes

The only way to ensure people bring 100% of themselves to work is by making sure that they find their work interesting. A conversation about aspirations can help make this happen. This conversation can be broken down into 3 steps:

  1. Dreams: A good way to start the conversation on aspirations is to ask people to imagine what the pinnacle of their career looks like. Ask them to articulate the most important things they want to achieve when they are at the top of their game. This question can elicit interesting responses, such as “I want to deliver a TED talk”, “I want to be a community leader for women in tech” or “I want to be an expert in typography and create a series of typefaces that will last for decades.” Together, try to create a list of 3 to 5 such dreams with your direct report.
  2. Skills: Achieving dreams often requires one to gain new skills or improve existing ones. For each dream, write down a few necessary skills. For example, to become a community leader for women in tech, one might need deep technical skills, public speaking skills and people management skills. These are the competencies that will help the individual make their dreams a reality.
  3. Values Check: Sometimes, people’s dreams do not align with their skills and values. For example, a person might want to be an entrepreneur (dream) managing a large team working on complex problems (value), but at the same time she might want to contribute really high-quality code (skill) herself. It can be quite difficult to contribute deep technical work while fulfilling the entrepreneurial responsibilities of running a company with a large team. As a manager, your job is to work with your direct report to help them find their area of focus and be successful by aligning their values, dreams and skills.

Step 3: Growth Plan

Recommended time: 45 – 60 minutes

Now that there exists a list of skills that the individual needs to achieve their dreams, it is time to create a personalised growth plan that creates opportunities to hone them. For instance, if your direct report needs to enhance leadership and product direction skills, create a growth plan that allows that individual to work on a project where little or no product direction has been set. Provide an opportunity to lead a small team. If your direct report needs to develop a deep technical skill, offer an opportunity to work on a project filled with challenging technical problems.

A personalised growth plan helps one choose their own career trajectory at a pace they are comfortable with. Alongside helping the individual feel like they are moving towards achieving their dreams every single day, it helps the organisation align business priorities and expectations across the board.

Repeating the career conversation

At the next meeting in 6 months, we go through each step again but with a mindset to adjust and course correct. Shifts in values and aspirations occur constantly, so check in to see what changes have occurred. Update the growth plan to account for these new expectations. Healthy businesses are a function of happy individuals who bring 100% of themselves to work every single day. That only happens when individuals see a path to their ultimate success at their organisation.



If you’re looking to work in a company that invests in you, you should know we’re always hiring. 

We’re looking for engineers, designers and researchers across all levels and would love for you to join the team.

Read more

As a small team of digital product strategists, we’ve helped realise some world-changing ideas, both in the for-profit and not-for-profit space. But changing the world is not our calling. It is just a happy byproduct of what we really want to do – make this complex world of ours, exceedingly obvious.

We’ve dedicated our lives to this mission and have evolved methods and best practices that have helped us solve complex problems by delivering solutions that are dead obvious. 

Time and again, a lot of talented people have reached out to us, expressing interest in learning from our practice, and applying it to their work. To facilitate this learning, we’ve decided to launch, for the first time ever, the Obvious Residency Programme.

About the Residency

Our residency comes in 2 flavours: you can choose to either work on a passion project you’ve been wanting to bring to life as a Solo Explorer, or you can join our team for the duration of the residency and contribute to an exciting client project that we’re working on as a Co-Conspirator! Here’s more information about the residency programs: 

The Solo Explorer

Work on your own passion project

Do you have a project idea that you’re itching to start working on? Do you need funding and guidance to make it come to life? If yes, then this is the programme for you.

Here’s what you get: 

  1. 6 months of our time, energy and resources
  2. Inputs from our team of 15 designers
  3. Access to our network of creatives, entrepreneurs and VCs
  4. Healthy lunch at our sunny office
  5. Ergonomic furniture
  6. Funding for all project related needs + a stipend to cover the cost of living in Bangalore

The Co-Conspirator

Work with us on an exciting client project

Are you more excited about the process than the end result? Do you want to become better at your craft? If yes, then this is the programme for you.

Here’s what you get: 

  1. 6 months of our time, energy and resources
  2. Inputs from our team of 15 designers
  3. Access to our network of creatives, entrepreneurs and VCs
  4. Healthy lunch at our sunny office
  5. Ergonomic furniture
  6. A full salary commensurate with your work experience
Our Sunny Office Library

What Do We Expect From You?

If you’ve read this far, and haven’t lost interest, you’re probably wondering – “What are they looking for? What’s in it for them?”

At Obvious, we’re always looking to make our studio more interesting and diverse. We believe that by bringing in residents who are willing to take risks, are itching to build something exciting and can challenge our thinking, we will continue to grow into a more well rounded team. By helping you learn, we hope to become better ourselves.


If what we’ve outlined sounds exciting to you, then apply using the link below and we will get in touch with you soon! 

Apply to be a Co-Conspirator or a Solo Explorer.

Read more

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
1 2