A hypothetical conversation is taking place in a conference room between a software engineer and a business user.
"I need to have the development team available and ready twenty-four by seven during the filing period. This is Fed mandated SLA and we would have to react within 4 to 24 hours. If any approval is needed to do immediate deployment to the production, secure the necessary management approval upfront.", said the business user.
"Do you really need the development and production support team to seat at their desk and waiting to jump in to reintegrate the financial models into the production environment? What problem you are trying to solve here? Are you looking for a way to have the changed models reintegrated into the production environment within a short period period of time to meet the stringent Fed mandates SLA?" The software engineer replied with an empathic voice. Further adding to it by proposing a potential solution to that problem, "How about we provide you a self-service capability to reintegrate the models into the production system? You can do that anytime you want it and any number of times you need it."
"That sounds interesting but I don't want anyone to change the production system anytime without a proper approval", the business user reacted in a receptive tone.
"I don't want that either", the Software Engineering Manager is now chipping into the conversation, "We can enforce four-eyes check but let's talk more about the detail before we jump into the final solution", and has steered the discussion towards finding the right solution.
Though this may be a hypothetical conversation but certainly you have seen the similar conversation where the business user approaches the software engineering or product development team with a "brilliant" IT solution of a business problem without even mentioning what business problem the user was trying to solve. However, the goals of the software engineering team should be to steer the conversation towards understanding the users' pain points, find the fundamental problem and then propose the right solution.
To me, this is the essence of Design Thinking.
To me, this is the essence of Design Thinking.
Design Thinking is a not the new guy in the town even though its reincarnation sounds just like that. I don't want to spend whole lot about its historical aspect but let's put just enough history for the sake of giving a context.
Design Thinking as a concept came into existence in the late sixties when Herbert A. Simon published his book, "The science of the Artificials". This got into the mainstream through the establishment of Stanford University's Design School.
Before delving into the detail of the Design Thinking, let's first clarify, "what's Design?"
Design, though it sounds like the surface or outward appearance of a thing, however, this concept of design is furthest from that vain outwardly look and feel. IBM Design Thinking defines Design as "The Intent behind the outcome". But the most intricate definition of Design came from the man who had changed the way we perceive the computer products, Steve Jobs, who once said in his interview that the reason he doesn't like the Microsoft's product because "it doesn't have the taste", and defined Design as "...the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers". And Design Thinking is the art of creation of Design.
Now, let's take the words from two other most influential persons who have helped the Design Thinking to come to its current state: Don Norman, the author of "The Design of Everyday Things", has described the Design Thinking as "...Designers resist the temptation to jump immediately to a solution for the stated problem. Instead, they first spend time determining what basic, fundamental (root) issue needs to be addressed. They don't try to search for a solution until they have determined the real problem, and even then,, instead of solving that problem, they stop to consider a wide range of potential solutions. Only then will they finally converge upon their proposal. This process is called design thinking." and Tom Brown, the founder of IDEO, has defined Design Thinking as "...a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people, the possibilities of techno technology, and requirements for business success".
In the second part of this post on Design Thinking, I will cover the method of Design Thinking and shed some light on the IBM Design Thinking and finally on how the Agile development methodology can coexist with Design Thinking.
No comments:
Post a Comment