Nicolò Andronio

Nicolò Andronio

Full-stack developer, computer scientist, engineer
Evil Genius in the spare time

Design thinking for developers, or how to solve the right problem

Published on
Last updated on

As developers, software engineers and software architects, we are often enamoured with the world of technicality. We strive to come up with efficient solution that strike a balance in an ever-changing panorama of fleeting requirements and users’ whims. As such, it’s quite easy to always analyze the problem from nearby, lacking an eagle view of the bigger picture.

A builder is content with her construction on Earth but the astronaut that observes everything from afar scoffs and marvels at the stars beyond.

So how can design thinking help us grow as developers in order to appreciate complexity at multiple levels of scale?

What is design thinking?

Despite originating in the field of inventive business with an Harvard article by IDEO’s CEO Tim Brown, design thinking evolved to adopt multiple shapes throughout the years. I was introduced to this concept less than an year ago but it did change my perspective on software engineering. Or to better put it, design thinking allowed me to ask more interesting questions before plunging into implementation. As developers, we are often focused on building things right: with some experience in the field and the support and expertise of equally skilled co-workers, I now tend to assume this is a given. Of course, there are always pitfalls but they are much easier to spot from afar. Instead, I shifted my attentions on the other side of the coin, i.e. to build the right thing.

Enough with abstract ideas now! Let’s make a concrete example and see how design thinking allows us to walk around a problem and achieve a better understanding. Afterall, pragmatism does not exclude creativity!

A simple scenario

Let’s say you are working as full-stack developer for Awesome Bank. The home banking is quite new and has been developed recently. Here’s the initial home page, in its simplicity:


Initial home page

On a Monday morning, your boss comes to you with the following request: “A client asked whether we could put the actual account balance figure within the button to access the account balance. Do you think you could have it done for Thursday?”. You scoff: easy enough! It’s probably going to be done within the morrow, but better to take it easy and make sure the code is clean and tested. On Thursday, your boss sees the new update and is quite content with the results. The following week, he visits you again. This time he asks you whether it’s possible to remember the last page the user visited before logging out, and to show the same page when they log back in, but only if it doesn’t contain an input form, so it doesn’t look too empty. Another easy request. Done and done! Then you keep on with your working week as normal. The same pattern repeats with slight changes for many months, until the application is full of links, special rules for redirects, scattered info and so on, but it doesn’t matter because you did your job. You built the thing right, with all the best coding practices, and that’s exactly what you’ve been asked for.

Can you spot the problem? Yes, you may have built the thing right. But did you build the right thing?

Step 1. Empathize

Let’s look back at what happened in the fictitious scenario exposed above. When the first request came in, we gave it for granted. The user directly asked for a solution and we implemented exactly that. Did we stop for a second to try and understand the problem which caused the request in the first place? No, we didn’t. That is the crux.

Design thinking is an iterative process that can help us create better solutions. Its first step is simple: empathize. It means we ought to share the same feelings and surface thoughts the user has and try to internalize them. Through this practice, we can acquire a deeper truer level of understanding for the problem. And how do we do that? By simply asking our users for feedback. Unfortunately, asking the user is often seen as a scourge in the field of software development. Higher-ups and managers think it shows weakness and lack of direction. That is partially true, but no product exists without consumers: building a solution no one uses is no better than building nothing at all.

When practicing empathy, in the more technical meaning of the term, we acknowledge the same pain points the user finds in the platform, i.e. those operations that feel more cumbersome, slow or unintuivite. Listing pain points is an excellent way to frame the problem in the right way, highlighting what doesn’t work instead of patching it hastily.

Let’s say we adopt this approach in the current example. Asking feedback from users allows us to discover that many share the same opinions:

Ah-ah! It’s easy to see a trend here. Users complain because there’s a lack of a place that quickly summarizes their account at a glance. Now we understand the problem better and can start working on a solution… but wait! Hold your horses! Don’t open your IDE just yet. We need an injection of creative juice here.

Step 2. Ideate

This is the step where we go back to the drawing board. We need to realize that our current user experience does not cater to the audience of our platform. Whether that means we didn’t investigate hard enough during our first implementation, or whether our clientele changed over the course of time, it doesn’t really matter. Well, it does matter in general to further the betterment of the team strategy of course, but it does not affect the current step that much. During the ideation stage, we should brainstorm new ideas that address the problem we already discovered. It’s important to notice there should be no limit to the range of exposed ideas: some will be grand, others will be niche, but all input is meaningful; especially considering no idea ever wins single-handedly. It is the compoud contribution of everyone’s thoughts that concurs in forging a final hybrid solution. For example:

Step 3. Prototype

Now is the time to dust that old Figma account, and create sketches, mockups and designs. Event paper prototypes are fine! A lot of people are more comfortable sketching their ideas on a blank piece of paper. Personally, I don’t like it since it’s too easy to misunderstand the “scale” of elements, often ending up with disarmingly blank pages when the prototype is transposed into digital format. Alternating between quick mockups and actual working prototypes is also fine. While working on my latest product, we spent a month implementing a prototype in React, without any underlying functionality, just to craft the right user experience.

Regardless of how you decide to go about the prototyping phase, bear in mind it should consider these main points:

For example:


Initial home page

The mockup needs not be complex, but should strive to account for most of the pain points we singled out in the first step. Solutions can be considered emergent properties once the problem is well understood.

Step 4. Implement

Now is the time! We understand the problem, we have a valid prototype that will hopefully address the issue. Let’s open the gates and implement something the works. And once that’s done… rinse and repeat. Design thinking is an iterative process. It is a neverending cycle of improvement and change: audience may change, requirements may change, thus it’s only natural that solutions may change as well. Don’t forget the crucial part of this process, though: feedback.

Feedback steers the boat in a sea of uncertainty: the unprepared sailor is victim to the whims of waters, but the savvy captain always governs its ship towards a safe harbour.

Enjoy the content?
🍨Buy me ice cream