We’ve all been there: involved in an exciting project that fizzled out or failed. Maybe it was because feelings overruled facts. Or colleagues debated endlessly. Or dev teams coded untested solutions when you could have been testing live prototypes with users.
Or maybe the HiPPO—highest paid person’s opinion—got in the way. 🦛
In spite of talent, desire, and our best intentions, projects fall down without upside-down app design and development. But what does that mean?
Recently, Skuid Founder and Chief Strategy Officer, Ken McElrath, sat down with Forrester VP and Principal Analyst, Jeffrey Hammond, to discuss just that.
If you want to:
- create effective digital solutions to complex business problems
- push more app dev projects to completion without sacrificing quality or user experience
- or simply help users get things done in fewer clicks
Then this is the place for you.
Why is upside-down app design and development critical?
Just as it sounds, upside-down app design and development seeks a different approach from the standard. The goal is to first understand the business problem deeply before jumping to the solution or a particular technology. The process produces better user experience and improved business outcomes.
If your answer to any of these questions is “yes,” you need an upside-down app dev approach. Do your users:
- Need rewards or punishments for motivation to use the system?
- Report it takes too long to view or enter information?
- Have to navigate to several different screens to find what they need?
- Prefer alternative solutions such as email or spreadsheets?
- Require a cheat sheet to use an app?
- Take weeks or months to understand the system correctly?
These issues present challenges in and of themselves, but they also produce dire organizational consequences.
When people aren’t using your app as intended (and everyone knows it), the company begins to mistrust your data. If your system is too complicated to use, your support team gets buried with calls and requests. And when employees can’t remember how to use an app after months of effort, they get demoralized.
With any system, the only two things that matter are adoption and delight. If you can produce solutions that achieve those outcomes, you can begin solving complex business problems.
"The real purpose of every app that you build: enabling people to take advantage of super complex technology without forcing them to understand what's going on behind the scenes."
– Ken McElrath, Founder and Chief Strategy Officer at Skuid
The role of human-centered design in app development
When it comes to solving a problem, human-centered design (HCD) starts with the users. This is key: forget about the technology at the outset of discovery and make sure you really understand the problem. This concept isn’t new; it’s just not considered as often as it should be.
“So many times we focus on the technology and are ignorant of the culture that we're using to build the solutions, the talent, and the organization,” Jeffrey says. “What I increasingly find is in some ways, the technology is getting easier and it's the cultural challenges and the organizational challenges and the process challenge that trip organizations up all the time—not the technology.”
Once you truly understand what the user desires, then begin to overlap the feasibility and viability. This helps you arrive at a solution where the business requirements and the technology stack are aligned.
"You can have 100% overlap between feasibility and viability and still build apps that nobody uses," says Ken.
The best way to drive adoption is to create an experience that gets people excited about the technology. To do that, consider the four aspects of “big D” design:
- Utility: can the user accomplish tasks with the app to reach their goals?
- Efficiency: can the user perform work faster than with the available alternative solutions?
- Clarity: can the user quickly see how the app works and use it without training or consulting a manual?
- Delight: does the visual appeal of the app inspire confidence in both the tool and the people who crafted it?
By focusing on big D design, you create efficient apps that people actually use. Big D design helps organizations focus on the connection points that really matter.
For instance, one Skuid customer had a complicated process for performing parachute-packing inspections—a mission-critical task. Using Skuid, the customer took the inspection process down from 49 clicks and 7-8 minutes per parachute to four clicks and 40-50 seconds, accessible on mobile, too.
The ROI of HCD
First, building an app that leads to greater productivity for anyone that touches your customers means fewer lost opportunities. And that leads to revenue.
Yet, while everyone focuses on revenue when considering ROI, cost savings is important, too.
Also, ROI isn’t always tangible in the traditional sense. Linus Pauling, a two-time Nobel prize winner said, “The best way to have a good idea is to have lots of ideas.” Human-centered design, paired with the right technology and organizational culture, promotes experimentation with these ideas.
“One of the things I think you need to measure is how does this increase our ability to take our ideas and put them into practice, to test them, to get them out there? Because the more innovations that we can test, the likelier that one of them is going to be a star."
– Jeffrey Hammond, VP and Principal Analyst at Forrester
Design thinking: the key to human-centered design
Design thinking involves tackling a design challenge by coming up with as many ideas as possible to solve it—in other words, using divergent thinking to arrive at the best available solution. Once ideas are on the table, convergent thinking narrows all potential ideas to the best one.
Sounds great, right? But too often great ideas go to die in the design-thinking graveyard. Here’s why:
When it comes time to converge, most companies don’t have the right tools or processes for experimentation. Yet, to create a mission-critical solution, you must test with users in the field. When working prototypes take months and countless lines of code to develop, budget evaporates.
"If you want to move to a faster method of value delivery, the most important thing is being able to let go of perfection and embrace speed, because if you don't pair divergent thinking with speed, then you’re creating a recipe for disaster," says Jeffrey.
Traditionally, the world has thought about software delivery as an engineering process with efficiency and standardization as its goal. With that mindset, making mistakes is bad.
But, if decision-makers can shift their thinking on this topic, making mistakes is actually good. That process just needs to happen fast. When developers prototype many ideas and employees and customers test those ideas quickly, you expose what truly works and what doesn’t.
Beware the pitfalls of Conway’s law
When it comes to development, companies are constrained by their ability to communicate effectively. Conway’s Law is essentially this: organizations design systems that mirror their own communication structure. So, while an agile development approach is superior to waterfall development, it won’t help much if your organization operates in silos.
“These silos within our IT organizations have created a situation where developers don’t see themselves as designers,” Jeffrey says. “Their view is, ‘Design is not my job. I take the functional requirements or the backlog and I do what it tells me to do.’”
This kind of thinking permeates the entire IT organization, and each team involved throws its work over the wall. So, if you don’t tackle the cultural communication challenge first, you wind up with systems that don’t meet user needs.
What’s the alternative? Everyone needs to be part of the process from start to finish. We can’t allow specialization to diminish the humanity of the people who will build the solution.
“When you hand something off to a software engineer and say, ‘Okay, here's our requirements. Just go build it,’ that seems so dehumanizing because these are brilliant engineers, right?” says Ken. “They want to be part of speaking into that solution, too. So, you have to figure out different ways of interacting as a company.”
Focus on flow
If your company operates in silos, change that by focusing on flow.
Instead of teams thinking “Have I done my part of the job?”, rally around shared purpose and how you’re moving capability through the system.
To maintain flow in the context of design thinking, you also need to lower the cost of experiments.
Since divergent thinking (and the ability to act quickly on those ideas) is key to coming up with the best solutions, consider how you can facilitate more of it, reap the maximum benefit, and change the way you think about interacting with customers, too.
Another barrier to communication and flow could be your organizational toolset. When everyone is using different systems to progress their work, that creates silos, too. So, invest in processes and platforms that play nice together.
"Low-code lowers the cost of divergent thinking, and that’s powerful."
– Jeffrey Hammond
How to put upside-down app dev into practice
To practice upside-down app development, start with the phases of design thinking. Begin with a divergent idea. Then consider the most important ideas you can put in front of users to test.
As you go into follow-up sprints, understand the data you’ll get from experiments may force you to diverge again. Focus on what you’ve proven, what you’ve uncovered, and what will allow you to move forward.
Upside-down app design and development requires a mindset shift: you’re working on a product that will evolve over time, not a project with an endpoint.
Transforming app design and development in your organization
All this sounds well and good, but cultural change is hard to affect. You may want to try some of these experiments but where do you start?
One way is to start thinking differently about shadow IT. Instead of trying to squash it, ask why it’s happening. Embrace the fact that people are just trying to do the right thing for the business and the customer.
Then, study what people are trying to use and duplicate it within your IT structure, displacing the need for workarounds and rogue apps.
When core IT makes services available across the organization, it gives teams the tools they need to focus on the customer experience without having to worry about complex technical details. IT gets what it cares about most (ensuring data security and constraining processes) while those closest to the customer maintain control over that experience.
Beyond rethinking shadow IT, look for opportunities where disruption is already occurring in your organization.
Jeffrey explained that one of the blockers to using new technology for app delivery is “the leap of faith.” He shared that Forrester spoke to CEOs at large companies asking them what they needed to know about software development. They found that, while CEOs see development as important, they don’t always know the right thing to do.
At a certain point, these leaders need to trust someone in IT and make a leap of faith. You can build that trust by encouraging small leaps of faith that you deliver on over time.
“And what happens is as those first leaps of faith get justified, the appetite for taking larger leaps begins to grow,” says Jeffrey.
And remember that in IT, it’s better to be fast than perfect.
For more app design and building tips, check out our eBook Five best practices for accelerating Salesforce app development and improving user experience.
