Hi @Anamol_Shrestha, thanks for sharing and bringing this up!
I’ve used a similar process to yours and teach client teams how to fit the Design Thinking Framework into their agile product team processes. I like the iterative nature of DT because it fits well into most agile frameworks product teams are already using while focusing on the people your solving problems for. The UK Design Council’s updated Double Diamond process is similar and has also worked well for clients.
The only major difference in steps is we’ve often brought the “Implement” or Materialize step further up as part of prototyping potentially. It really depends on how well the problem is understood from our research insights and the risk in getting feedback on development iterations vs prototype iterations. Is this a brand new solution or adding to something existing? How well will a prototype get feedback vs some MVP in code? These types of questions will determine when the implement step starts.
Our methods are similar to yours, but we leave out competitor research and spend more time on qualitative research methods across the board. Interviews, observational usability studies, they really cut the overall UX and dev time down. We might also use a design sprint (ala GV style) for the Explore steps (Solution Research + Design Solution + Tech Analysis + Feedback) for challenging/riskier problems.
The other process piece I push for is the Understand step in DT is always happening in parallel (dual-track) to feature work. Usability testing after delivery iterations, research across the company’s services to look for needed improvements, problem discovery from UX research. We usually focus on user/customer/people research during these separate tracks of work.