The Importance of Design Thinking Early in the Development Process

Software development is a complex process, involving interlinking components that depend and build on each other to form a functional application. Having to go back and rebuild foundational components in an application has a detrimental effect on the development process, wasting the resources invested in existing work and potentially undermining ongoing work. To avoid this, you should carefully consider the design of an application, including how users interact with it, before your first code commit.

Of course, perfection doesn't always happen the first time around (actually, it never does). New use cases and improved methodologies will always arise after the outset of development, as well as far into the lifecycle of a mature product. Long-lived, popular applications will need to go back to the drawing board at some point to revise core functionality to keep up with user expectations.

As I discussed in the first article in this three-part series, we had identified that Appsmith's UI-building interface had fallen into the same trap as many other internal-apps platforms — it was easy to use, but building out user interfaces (UIs) was a tedious process, especially for users wanting to focus on their app logic rather than micromanaging UIs across different screen sizes.

This article continues our look at our proposed solution to this — intent-driven design — as well as discussing the importance of design thinking early in the development process.

A proposal to solve UI building woes: introducing intent-driven design

Design is all about the consumer. Design thinking is considering how users will interact with your product and interpreting those needs to provide an attractive and highly usable experience. Developers are usually focused on functionality and logic, and how the user will interact with their application is often left as an afterthought. It’s vital to dedicate time in the planning stages to thinking about how the user will use your platform: design choices should go hand in hand with implementation choices so that they don’t cause roadblocks for each other during development.

It was only after Appsmith had taken off that we identified that the current industry-standard paradigms for UI design tools were slowing down our users. More in-depth design thinking in the early stages of development would have preempted this, but it’s never too late to correct course. That's where my specific talents come in. I’ve been working on canvas-based tools for almost a decade and have over 20 years of experience in UI design. I absolutely love exploring new ways to improve UI usability, so working on overhauling Appsmith to create a ground-breaking new developer experience presented an exciting opportunity.

We wanted to drastically speed up the process for our users to build user interfaces for their apps. In my years in the design field, I’ve learned one thing: UI designs and interactions are not magical; they’re usually just a repetition of already proven design patterns. Given this, and given that most design rules can be codified, I proposed that we automate our UI-building interface. We didn’t need to wait for some magical interface-building AI to come along — we could do this within Appsmith with currently available technologies.

As part of both my professional and personal passion for UI design, I have been experimenting with intent-based auto layouts. In my technical demos, I had successfully distilled the normal action chain for adding a UI element to an interface (add element → resize element → move element) to a single action (just add the element by dragging it onto the canvas). Accomplishing this required reading the user's intent: figuring out where they wanted the element to go and what size it should be relative to what's near it, and then setting the position and dimension when aligning, grouping, and reordering UI elements. I was able to take this even further by interpreting the movement direction and velocity of an element being dragged on the canvas to better determine what the user wanted to happen.

This was a perfect answer to the problem we were trying to solve for our Appsmith users. We would overhaul our UI-building interface so that it could read the user’s intent and automatically enforce good design patterns — liberating them from having to learn UI design and make tough design choices and just letting them build. This automated approach would also reduce the surface area on which potential design errors could occur: Appsmith apps would look good by default, unless the user really went out of their way to try and build a bad UI.

The importance of audience research early in development

The best time to solve a problem is before it happens. This isn't always realistic, however — sometimes, especially in software development, and especially during that rush to a minimum viable product (MVP), you have to “make do” with something that works, knowing that you’ll have to perfect or replace it later. This is part of every project's dreaded technical debt.

An application's design and user experience often fall into that “perfect it later” category, to the detriment of both the quality of the released product and future development. They shouldn't — design is foundational.

Many architectural decisions and much supporting development work go into making an application's UI behave a certain way, all based on the design and the design thinking behind it. Your users will also become comfortable with, and build habits around, your UI — so if you make any major changes, you need to be able to justify them to your users as well.

“Perfect it later” could mean throwing away a lot of development resources and customer goodwill that had been invested in a solution that was never going to meet its goals. This isn't to promote absolute rigidity: to make the best of the resources available at Appsmith we make compromises; we polish core mechanics first and avoid doubling down on features which could be safely added later. Decisions that are reversible or have a transition path can be ”perfected later.”

The trick is to orchestrate all dependent initiatives and test/ship them with the right priorities. This way, even if ”later” never happens, we still have a decent product. Identifying and ranking these priorities requires thorough research on your intended users and their use cases.This is best done by understanding what they aim to accomplish with your product, not necessarily how they think it should behave. What users need is not always what they want, and what they want is not always what they ask for.

This is especially important if your product is complex, for example a software development platform like Appsmith. When we ask users how they could build better UIs using Appsmith, most of them suggest increasingly granular control, which, if implemented, would eventually result in a messy Appsmith interface and poorly designed end user applications. Through our research we found that by limiting what users could do to what they needed to do, they found building their own user interfaces much easier.

Like selling a sports car to someone with a big family, giving users what they want isn’t always best for them. Design thinking during development addresses this by giving you the opportunity to fully conceptualize how the application will be used, and build to that.

The less extensive your insights into the intended audience for your product, the more re-working you’ll need to do. Changing the design of a mature product isn't just a major technical task — an existing user base will always have some aversion to change, requiring additional consultation, testing, and support to manage the potential impact of the changes.

The importance of ongoing consultation with your users

In our experience, those who are actually averse to change are a vocal minority. Most users generally do want to see the platforms they use evolve over time, rather than see them stagnating. New and better ways of doing things are always being discovered and your competitors are always trying out novel solutions and ways to improve their products’ functionality over yours to siphon off your users. While we've found that some changes are initially uncomfortable as users revise their workflows, they become “natural” after a short adoption period — as long as the new features provide a clear advantage to users and they feel like their opinions and feedback were valued and fully considered.

Appsmith's product category and audience means that we emphasize our existing users — internal apps developers expect a stable platform to build on, and breaking existing apps would be a sure-fire way to annoy them. We'll happily help our users break any bad habits they may have by giving them more intuitive tools, but we won't undo their existing hard work or make decisions that will have negative outcomes for the Appsmith apps that they’re building their businesses on.

In terms of automating our UI-building interface with intent-driven design elements, we’re confident that we’re satisfying the needs of our existing users and making Appsmith easier to adopt for new users. While we did have some concern about removing the ability to create 100% arbitrary layouts, our users have responded incredibly positively as a whole, preferring the time savings of automation over having 100% control over UI positioning. We’ve also been able to maintain backwards compatibility — our tests show that most legacy applications will be auto-layout friendly with minor modifications, and while there are some legacy apps that couldn’t be recreated using the new layout engine, they still work as they were initially built.

Overhauling our interface was expensive, and it would have been much better if we’d identified our users' needs earlier in the development process. We did consider allowing for arbitrary UI positioning alongside implementing the new intent-driven system, but this would have added to that cost as we would have to maintain two positioning modes in parallel, and users would have had to deal with the downsides of compromising and combining both approaches rather than the clear benefits of our chosen solution.

Getting the design right as early as possible is important, but it's just as important to ensure the technology behind the design leaves room to maneuver, iterate, and innovate in response to advancements in user requirements.

Always be ready to re-evaluate your choices, otherwise your product will stagnate

Innovating a mature product means being willing to tear up something that works to build something that is better. But you can reduce how much you need to tear up by making good design decisions early in the development process.

You should also maintain a healthy relationship with your users so that you can stay informed about what they want, and how they are using your product, so that you can figure out what they need and deliver it. Good design thinking will also make for a better iterative process in your product lifecycle, so that you don't make updates that later have to be reversed (or, again, torn up and replaced).

Our decision to reinvent our internal-apps platform’s user interface was a big one. Changing Appsmith’s core functionality after it had already been put to work by our users in their own internal apps came at a huge cost compared to doing it right from the outset, but we decided to do it — intent-driven design just seemed like too big an opportunity to miss on behalf of our users, who we knew would benefit greatly.

Fully implementing intent-driven auto layout has been a major accomplishment, but it's just the beginning for intent-driven functionality in Appsmith. We want to automate as much as possible, from UI positioning, to theming, all the way to automating the creation of entire application layouts. In our upcoming article, we will delve deeper into the future of intent-driven design, to see what the future holds for internal-app platforms.