- SAP Managed Tags:
A year back my experience with Design Thinking started, and I have found it interesting in all aspects.
Coming to first W, What is Design Thinking.
Design Thinking is not an altogether new way of software development life cycle mechanisms, it fits well to both Waterfall as well as Iterative development model.
With my experience it has worked well with our team, with Agile mode of development.
Design Thinking contributes to the software development, rather than defining the development.
Coming to the next 'W'. Why Design Thinking
Design thinking helps one to gain skills to know what the customer really wants and understand his needs and develop solutions for him.
From a business perspective, it helps to form a new business strategy and creates new oppurtunities.
In this blog, I will be posting my experience as a developer, and will be dealing with the things which I found better for our team with respect to our day to day work.
Coming to next question, H, How Design Thinking
As I have mentioned Design Thinking is not a new process. Given a problem, a developer needs to understand first what is the problem about, why the problem has come, what is the reason behind usage of such a scenario. Practically speaking we all have thought 'What' 'Why' 'How' for all problems/issues we face in our day to day life. The thought process behind that decission is so fast and instantaneous to us that we dont realize the stages of how our brain arrived at that decission.
This thought process can roughly be termed as Design Thinking, the only change being we dont have that problem while customers have it.
So the first step from our side should be to put ourselves in customer's shoes and understand his problems, which we term as 'Empathize'.
So from our team , couple of developers went to the customer site and observed their activities and luckily the problem was also fixed.
There are some instances where the customers would not realize it as a problem, as they would have been used to it, that day in day out they dont realize the
actual problem there. In that case it is upto us to find out why they do what they do and that would give us more insights and help us realize potential bottlenecks/ problems in it.
On realizing the issues which the customer faces, we define the problem. This is the most important part from business perspective. If the problem defention is wrong, the next steps also would go wrong and hence the time, effort, cost we spend will become futile. So the defenition of the problem is finetuned and should be made very clear and precise.
So all our team members worked on the system just like how the end user whom we targetted worked. So we got a feel of what the problem is and how they resolve it. We had to now work on how they resolve it. We needed to know what all informations they needed to decide on a solution, and whether they need any approval from someother person, which could give us some rough requirement for a workflow or four-eye principle check.
The process which we worked on, is the actual Ideate phase, where we had to come up with different ideas of tackling the problem. We had lot of ideas, some questioning the problem itself, as in whethe problem itself can be stopped from occuring, some on how to fix the problem. We debated on why authorizations was required, what is that classified information which normal users are not allowed to see, while someone else can, and whether approvals are required, and why they need approvals etc.
In this phase, we have to question on everything and should never work with assumptions. Assumptions would play a spoilsport here and it would lead to lot of drastic unexpected results.
The ideation phase is little complex, as normally after years of working in the system, the limiations of the system creep into our mind, and we always work within those boundaries, the ideas which we come up with also will have the boundary conditions fixed. The more you are used to the system, the more problem you are bound to face during this phase. A fresh mind would definitely help, but it would take time and such person would not have able to empathize properly.
The important part is to balance the experience level in the system, and think not within the limitations of the current system.
We had a tough phase at this point as all the ideas which we came up with were within the boundary conditions of the current system, and we could not stop ourselves from thinking the feasibility of such an idea in our system. To get rid of that is not an easy thing to do, as the whole problem lies in our system and we should not thinking within the limitations of our system.
We worked on lot of ideas and after lot of discussions and finetuning, as a team we were able to conclude on an idea and we decided to have a mock model of it, to explain it to other stakeholders in our organization. This phase of preparing a mock model is what we call prototyping. We prepared a couple of prototypes, each had its own pros and cons and we tried to merge all the pros and reduce the cons and we could finally arrive at one prototype to address the problem.
The important part is in this phase which we realized as a team is to have the mock models either in system or in paper and not in just minds. In a team of ten members, each person would have his own view of the mock model, and such a thing should not happen. So we drafted the solution in paper, we drew how the screen would look, we drilled down to details of how the user would navigate from one page to other , even to the extent of no of clicks/no of user entries required etc. It is a time consuming phase, but it would help all the members in the team to be in the same page and would serve as model for discussion.
In laymans terms, the protoype was like a blueprint of the buildings , any discussions on it we could go to the model and show exactly what we are discussing about and related things easily.
Then we had decided to show it to the customers/end users of the system to check whether given a solution like this whether they would find it useful, whether it will address their issues and also the most important thing that our solution should not be the gateway to new set of problems. We validated with the customers and we got really good feedback and we worked on it and finetuned our model again, and again validated. This phase is the actual testing phase.
It was really a good experience as during this phase, we got some new inputs as well as we found that some informations were redundant and not required and some should be derived insights. So we got to know what insights they needed and we worked on it and came up with a model which they were okay with.
The advantage which I feel on adopting design thinking is that , we have a model ready and we are working towards it. And the team meetings and discussions all are very clear and each and every member in the team knows what we are working and why we need it.
During this phase, as I have mentioned before you can adopt any software lifecycle mechanism, we followed Agile and it has helped us a lot.
So essentially Design thinking helps us to understand the problem and build a solution for it, and most important aspect from the team which builds the solution, the team knows what they do and why they do.
This is my experience with design thinking , I would love to hear yours.
Regards,
Sivaram
