I personally do not believe the concept of a perfect design thinking process exists, every project is different and you will need to find the right way to tackle it, and the only way to do this successfully is understating your product very well.
Agile Environment + Design Thinking process
The concept of agile environments is very common nowadays and one of the biggest challenges I have faced in my career is how to include the design thinking steps into this methodology. Like I commented before, each project has different requirements and will need different solutions, specially because you usually do not start at the same phase or stage of development. I have personally implemented 5 steps that allow me to keep the end goal in front and I can pick any of them at any time because they are interchangeable. The reason why this is so important is because when you are in an Agile environment you should ALWAYS BE READY TO PIVOT the entire project.
My 5 Steps
It is very important to mention that these steps are not exclusive, they can happen at the same time if the project requires that, and I am always trying to improve this process from the feedback I get from the other stakeholders.
Understand the problem / Goal
Understand the user
Design / Deliver
Testing / Iterations
Understand the Problem-Goal / Research
To be able to understand the problem you need to meet with all the stakeholders, connect with them so you know their expectations, their limitations, deadlines, information that might be valuable from previous investigations, you need to make sure, you understand not only the problem in the present but how does resolving the problem impact the future of the company and the users .
You can read papers, essays related to the topic, probably somebody has already thought about the same problem for a different context. The more you know the easier it will be to find a solution in the future.
Understand who is your user?
There is two very common scenarios when it comes to design a product, you are either very close to the end user because you might be one of the use cases or you have never been in that position so you pretty much do not know anything about them. In both cases you need to be very careful because you are going to be doing the wrong assumptions and hypothesis. The best way to avoid this problem is being in contact with the user, maybe interviewing him, shadowing, see the behaviors, the processes, the interactions that you are trying to make digital.
The user will always be your source of truth, however it does not mean he is taking the decisions for you. One of the best ways to represent your users is defining PERSONAS including all the insights you have gathered from them
Evaluate all your information
Up to this point you have your problems , your users and you have a lot of information that will help you to make decisions. What is next?
You can do whiteboarding sessions for you or for your product team explaining everything that you learned, and see how all of this information aligns with the priorities they have in place to meet the deadlines.
You should be defining user flows, journey maps, gap analysis, make sure you understand the MVP for each feature and start thinking about how to translate all of this into a real and tangible product
For some scenarios is very good to do individual maps, so you can identify gaps faster if you have enough information, but sometimes when you are in the discovery stage still you need to some flows comparing the user experience with the business process, this kind of comparative maps will allow you to understand how many systems are involved, what are the end users you need the most and you can start thinking of how to merge all of this under the same design, or at least under the same product.
Design and Deliver
Explaining this step could get very long very easy but from a high level perspective there is some stages that you need to complete in order to successfully deliver your designs for either approval or for the Dev team. As I mentioned previously, my design thinking process is very flexible, it is always about adapting my ideas to get the best outcome, you don't need to do each step but it is always good to have enough options. This options are :
Very easy and fast to do and change in case you need to show and idea very quickly
Whiteboarding Sessions / Include as many designer as you can.
You do not want to start thinking about pixels and color before you understand your use cases and basic design patterns
Low Fidelity Prototypes
Now you are in front of your computer putting together everything you have learned and designed before. In case you already have a design system in place this step wont be necessary or vital because you can go directly into High Fidelity prototypes
Design Systems / UI KITs
This is not a step by itself but it is very important that design based on everything that the company has in place in terms of libraries and systems. In case they do not, this is the perfect opportunity for you to start documenting all of this components and start creating your own library.
I want to make an annotation at this point, having a complete Design System in place takes a lot of time and resources, it is pretty common to be confused between a library and a design system. But the good news is that there is always room for improvement, you will always find elements, icons, patterns that you have not thought yet or that the library does not have and this will the perfect opportunity for you to help the creating of this system.
High Fidelity Designs / Functional Prototypes
At this point you have everything almost ready too finish your first round of iterations, you have completed several steps to be here, your design should have that "final" look and you have a prototype where you can click and see the functionality designed, it can be as deep as you want and it depends in what do you want to test at the end.
Testing and QA
After you have your designs ready, your prototypes are working , you now need to go and test them, you want to test everything with the end users to make sure you have met the requirements. You will find edge cases, and sometimes it will require a period of adaption for the users, but somebody that has a lot of experience in UX research once told me :
If you have to explain to the users how to do something one time and they learn it forever it is OK, what yo don't want is having to explain the same thing every time the user has to complete this task"
Once have tested the designs, and you have implemented the feedback given by the user you can deliver this designs and explain them to the whole team again, you should always include devs during your design process to find technical limitations so you can be realistic about the final outcome. But you are human, you make mistakes and that is why it is important to always be flexible and keep iterating. You know will be adjusting grids, finding that you misplaced text, typos, fixing sizes and making sure they are ready to start coding.
And this process never ends, you keep iterating .