A confluence of business trends and development best practices is changing the way developers need to think about building applications.
For want of a better term, the mindset that most software developers follow when building applications might be called ‘systems thinking’: Design a database that holds the data the company needs, design the software components that manipulate that data, and, finally, create an application that uses those components. Only after the application is built are users brought in and trained in how to use the application. This process creates applications that weren’t so much implemented as they were inflicted on users.
In an increasingly integrated world where customer and employee engagement is critical to success, that kind of thinking isn’t going to work anymore. Design thinking provides an alternative way to build applications that begins with understanding users rather than tacking them on at the end.
It would be a mistake, however, to think of design thinking as something new (though the term was popularized for businesses in 1991 by David M. Kelley’s IDEO consulting firm). As Sarah Gibbons of the Nielsen Norman Group points out in Design Thinking 101, design thinking has been around “for ages” (as she says, great designers have always used a human-centric process). Apple, for example, has been using design thinking when creating new products for over twenty years.
This approach shows up in multiple places at Apple, including their organizational structure: Apple’s design team isn’t required to conform to the needs of manufacturing, for example. This means that rather than designing the electronics for the iPhone and then figuring out how to put a case around it so that you could hold it, Apple designed the iPhone case you wanted to hold and then figured out how to fit the electronics inside it. Design thinking also permeates Apple’s processes. Apple, for example, frequently builds multiple early versions of any new version of the iPhone and then has company employees use those versions (we know this because these early versions keep getting lost). Based on the feedback from those users’ experience, Apple often makes an extensive revision to the phone’s design.
Greg Christie, an Apple senior software engineer, sums up Apple’s approach (and design thinking) when he says that Apple builds the iPhone so that “normal people – people with better things to do with their lives than learning how a computer might work – [can] use the product as well as we can.” That process isn’t obvious, however, which is why there’s only one Apple.
As Gibbons points out, what’s held up applying design thinking was developing a process that could be adopted and applied in a variety of disciplines (Learning Tree’s Critical Thinking and Creative Problem Solving course describes one version of this process). With those processes defined, however, design thinking can be applied in a number of places, including software development – in fact, current software development practices already embrace design thinking.
For example, as Avinash Singh Pundhir points out, design thinking is a great fit with Lean and Agile practices (Avinash notes that “Technology teams must have a granular understanding of user needs, behaviors and lifestyles to design solutions”). Design thinking is also reflected in the core principles for software development, summed up in the SOLID acronym (the SOLID principles are integral parts of both of Learning Tree’s .NET Framework Best Practices and Java Best Practices courses, for example).
The “D” in the SOLID acronym refers to the Dependency Inversion Principle. The Dependency Inversion Principle says the client that uses a software component should decide what the software component looks like – the client defines the interface exposed by the software component. This is the definition of design thinking, expressed as an axiom for computer programmers: The first step in designing an application is to design an interface that makes sense to the client.
In practical terms, this means beginning the application development process by designing a UI that makes sense to users (the goal of Learning Tree’s UX/UI design course, for example). Following the Dependency Inversion principle, it’s in subsequent steps that the software components that support that UI will be designed and built. Unlike ’systems thinking, the database design is the final part of the design process…or skipped entirely (as is the case when using Entity Framework).
It’s probably obvious that using design thinking to create applications that support customers, clients, or business partners is the only reasonable thing to do. As Steve Vassallo points out in his e-book, The Way to Design, “The 21st century will be the designer’s century, because the most interesting innovation is happening at the top of the stack—at the interface with end users—where technology meets design, and where a swipe right or a hold might decide the next breakout business.”
But the increasing interest in employee engagement means that design thinking makes just as much sense for the applications used by employees. Businesses are recognizing that it’s equally important to have employees whose goals are aligned with the organizations.
In a Forbes article, Alan Hall describes how organizations that have employees whose goals align with the organization’s goals succeed where other organization’s don’t. And this isn’t just ”management theory”: As DecisionWise shows in a recent survey, companies with disengaged employees have operating incomes almost a third less than organizations with more engaged employees. If employees are engaged – if employees’ goals align their organization’s goals – then designing applications around employees’ goals makes as much sense as designing applications around customers’ goals.
But this is all probably obvious: When an organization’s goals are aligned with both its customers and its employees, then the odds of success are improved. Using design thinking to build applications that support those goals, therefore, only makes sense. And when those goals aren’t aligned? Well then, it probably doesn’t matter how you build your applications, does it?