When building or designing an enterprise application, failure is not uncommon. In fact, more than a decade of research by multiple analysts shows that 30-60% of CRM projects fail. But, failure is a subjective measurement. A CRM project the C-suite deems a success thanks to colorful dashboards and predictive charts may feel like a failure to the sales team responsible for manually entering all the data feeding those dashboards.
Understanding how users feel about using your application helps you avoid poor adoption and create better applications in the future. If you hear users say it takes too long to get to the information they need in your app, or that the steps to enter or extract valuable customer information takes too many steps, you may have a design issue. Similarly, if you find it necessary to incentivize users to use the CRM because they don’t feel it’s going to help them work smarter despite industry data to the contrary, then again, you may have a design issue.
If you want to avoid the dismal industry-standard failure rate for CRM projects, you have to fundamentally address new projects from the user perspective. Understand what their problems and needs are before you even start thinking about technical decisions, budgets, or resources.
That’s where HCD and design thinking comes in.
Human-centered design in the development process.
HCD theory says that innovation stems from a struggle between three things:
- Desirability (do people want it?)
- Feasibility (can it be done and will it work?)
- and Viability (can we do it profitably?)
Too often, when organizations begin thinking about digital solutions to their problems, rather than driving the conversation and planning with questions of desirability (Are we solving the right problems for users? How could we create a game-changing solution?), they may jump first to feasibility and viability—things like tech stacks, security, data models, resources, budgets, and deadlines. Feasibility and viability are certainly important and must be addressed at the appropriate time, but too few spend too little time on desirability.
You can have one-hundred percent agreement and approval between viability and feasibility from the business requirements to the tech stack, but if you don’t factor in desirability first, you can still end up with apps no one wants to use.
To get desirability right, you have to involve potential users in the design of your application. When we start talking about design, many think we mean colors, fonts, spacing, and logos. This is not what we mean by design. As Steve Jobs once said, “Design is not just what it looks like and feels like. Design is how it works.” To understand how a solution should work, you will need to study how users get work done today. Understand their pain. Reveal the workarounds they have invented to overcome limitations. Ask how it could be done better.
Design cannot be ignored. Like it or not, we have only two options: bad design or good design. From our work with customers, we’ve developed four traits of a desirable, well-designed application:
- Utility: I can accomplish my tasks with this app and reach my goals.
- Efficiency: Using this app, I can perform my tasks faster and easier than I can with other alternative solutions.
- Clarity: I can quickly understand how to use this app without training and without consulting a user manual.
- Delight: The visual appeal inspires my confidence in both the app and the people who created it.
When you start by designing for user desirability, you can be much more efficient when you overlay feasible technical options and viability constraints to revealing the best available solutions. As you refine and focus, you’ll find that the greater the degree of overlap between desirability, feasibility, and viability, the more innovative and game-changing your solutions will become.
The three phases of design thinking and how it relates to building applications.
Design thinking, which related to human-centered design, provides a process for understanding the needs of the people for whom we’re developing applications. Design-thinking provides a way to approach problems with a beginner’s mind, coming up with options that may not have been considered previously, rather limiting options too quickly. Rather than starting with viability and feasibility, as discussed earlier, we instead address problems from a position of openness, curiosity, and creativity.
Let’s take a look at the three phases of design thinking and how we can tie them back to our app dev processes.
Design-thinking phase one: Inspiration.
You’ve heard the proverb, “Necessity is the mother of invention”? This is perhaps the best illustration of inspiration in design thinking. Some of the best and most useful designs—the wheel, hoses, ovens—came from someone recognizing a gap in the activities and processes we all encounter every day and coming up with an initial design for a solution. But the gap doesn’t have to be a necessity. We all use products we don’t necessarily need; but which, in some way or another, make our lives easier, simpler, or more efficient.
In application development, the inspiration phase is equivalent to the discovery phase, which should be the launch event for every new project. It usually involves a customer kickoff, along with a problem discovery and scoping phase where we sit down with the potential users of our solution and the stakeholders involved in its creation. Our goal in this phase is to expose everyone involved to the challenges users are facing and how those challenges impact their daily lives. Once everyone involved understands where we need to take the project, we can then start coming up with initial ideas for a solution.
Full exposure and participation of stakeholders are necessary because if you don’t give solution creators direct access to the actual users of whatever you’re trying to design, you’ll make incorrect assumptions leading to very poor outcomes that you can’t diagnose ahead of time.
Design-thinking phase two: ideation
With the user’s needs observed, gathered, and documented, you can begin to come up with ideas for potential solutions. It’s important to note that the end-goal here is not to completely map out a final product. This is where you put your ideas together and come up with possible solutions that you can then take back to users for additional input.
There’s no “wrong” way to work through this as long as you do it with the full support and involvement of everyone: users, developers, and administrators.
Design-thinking phase three: Implementation
Many projects fail In the implementation phase, and usually, handoffs are to blame. During handoff, those who sat down and mapped out ideas will hand the project off to the builders to make a working prototype. Unfortunately, when a prototype (often called a proof of concept) is handed off to a consultant or systems integrator to code, many thousands of dollars—even millions in some cases—can be spent before it is realized.
Weeks pass, and when a prototype is finally delivered, it’s so far along in development and so costly that changes are almost impossible. What we end up with—what we’re stuck with—is but a shadow of what was envisioned.
This is why in the worst-case scenarios, we’ve seen customers spend millions of dollars over multiple years with no actual working apps getting delivered. And when apps get delivered, they bear little to no resemblance to the utility, clarity, efficiency, and delight imagined during the design thinking process. Even when a project is a top priority, once code development work starts, budgets fade, calendars fill, and the initial energy and excitement fizzles out.
Successful design thinking with no/low code
HCD and design thinking significantly improve the processes by which organizations develop and bring new products to market. But, in many ways, it’s only now that we can take full advantage of design thinking, particularly from an application development standpoint.
Using no/low code in the ideation phase, we can quickly build and iterate on a variety of working prototypes in less time than it typically takes to map out just one with heavy coding. And as user feedback comes in, we can iterate changes and resubmit for additional feedback or approvals far faster than with traditional development processes.
Looking to the future, as users’ needs change, we can easily update our applications to change with their needs without having to worry about building up technical debt or needing to hire specialists in user experience or an antiquated programming language or framework the original app was built with.
To start building better apps today, check out Skuid on the AppExchange.