Building software with Empathy
Notes from an EdTech product team
Don’t make a better [x], make a better [user of x] — Anonymous
This quote sums up why this word empathy, has gained enormous relevance in software development in the past few years. For every team in a software company, be it product, design, development or customer support, empathy for the user should be a fundamental guideline on which the product is built.
Building a product according to the needs of the customer has its origins in the late days of the mass production. In those days what the factory produced was ‘consumed’ by the users and all products were without variation. The initially successful Ford Model T is an infamous example of this. When General Motors introduced newer models with better features, they were, in fact, responding to the needs of the customers who wanted more than just an ‘engine on 4 wheels’ that was faster than a horse.
Building products that users want to use
Though software products have existed for many decades now, over the past few years there has been a change in how they are built. Companies have moved from feature bloat to building things that users want to use and not forced to use. Responding to the needs of the users or risk facing obsolescence (to use the Ford analogy) has been a major reason for this change.
This change put the focus on the need for user empathy in software development. Empathy, which has been for a long time associated with design-led thinking and user-centered product management, can infact be used by all teams that are in the process of building software.
What is building with Empathy?
Apps of the Internet Age are now increasingly giving importance to solving real problems faced by users. Technology which was playing the role of a differentiator is becoming more of a facilitator in this journey. Empathy is not very different from words like Experience or Engagement that you have often heard associated with software development. Put simply, it means to bring the user to the center of any product decision you are having. Like I previously mentioned, they can hence be applied to any team that is building it and not only design and product management as traditionally known. Whether it is a small validation script that the developer has written to avoid unwanted input or a new test case by the QA member, every team can contribute to ensuring that the product is built with the user in mind.
For a product that is used in over 40,000 schools and colleges, we have building apps with emphasis on the user. From feature specs to code and test cases, our philosophy at Fedena has always been to simplify tasks for educators so that they can focus on what they do best — educate our future generations. This approach has helped us with making many of the decisions for Fedena in recent times. However, empathy is much more than that and when we first decided to take this approach we realized easier when starting from scratch. Something that is working just fine is in a state of inertia and it remains in that state — ‘If it ain’t broke, don’t fix it’. Then we made a conscious decision to take up the empathy-driven development approach for all feature enhancements one at a time.
A student management system has the first admission enquiry from a student to his leaving certificate and everything else in between.
The last release — version 3.5 was the first time we applied this approach comprehensively. It took the efforts of all departments — from UX to Development and QA to get started. If you have used the new version, you will be able to spot the difference in many areas. Implementing this was not easy and we are not there yet completely but here are 3 takeaways from this exercise so far:
- Put the user in the center of your product decisions: Often the decision that product teams have to take is how much is enough for a feature. Have we considered all scenarios? Is this required? An easy as well as difficult answer to this is to think as the user who will be using this feature. Easy because it gives you a canvas on which you have to take decisions, difficult because the canvas will often have many unknowns. However, segmenting and identifying your core user base will help give you the right direction to start with.
- Empathy starts and ends with the user: This is a given. Once you have this canvas you can start planning user stories around this. Be prepared to go further because there will be always something you could do more. If you have not thought through all the ways the user will be using the feature or product then you have not justice. An example that comes to my mind is from the CCE and ICSE examination system that we enhanced in v3.5. In this, the final result of an exam was calculated by schools in different ways. We brought in formulas like summation, difference and average as options. Then a teacher who saw the prototype said ‘Hey, the formulas are fine but we add up the final results is different’. This made us bring in two modes to handle the two different types of calculations.
- Be empathetic but not too empathetic: It is a corollary of the first two points but is equally important in your journey. You cannot build something that satisfies everyone. There will always be some features and some users where you have to say ‘no’. If you are able to define what you are as a product and what you are ‘not’ then this problem can be avoided to a great extent. You can read more about this in Product Strategy Means Saying No. It will also help keep feature creep away and over time only help your users by providing the features that they want to use.
Finally, you need to keep in mind that as with any other activity you undertake, there will be some quick results and there will be some that take time. The key here is to make this a habit and carry on. Once your teams start approaching your users with empathy, you will not only build better products but also make better users of your products!
As for us, we plan to continue with this approach in Fedena and keep learning. If you are interested, you can read about what are we working on. Have you tried empathy driven product development? What are your experiences?
