To solve a problem, you have to know what the problem is. This requires me to ask the right questions and talk to the right people. Whether it's through user interviews or external research, information gathering is crucial to understanding what is the problem and, almost as importantly, what is NOT the problem.
Once I think I understand the parameters, I like to represent it in various forms, whether that means drawing a diagram, writing it out, or verbalizing the situation to someone else. Often in my designs, I will use different mediums and approaches to explore a single problem. If you have a plaster model, make a drawing. If you have a user persona, make a user flow.
Once I'm submerged in the challenge, I'll use every brainstorming tool in the book to find a solution to the problem. Much of this process involves going back to the learning and reframing stages, but always pushing forward to search for answers. At this stage, every idea is worthwhile, and other people's input is crucial.
Make something. Even if it's rough, even if it's stupid. If there's anything I've learned in my architectural training, it's the importance of iterating through rough studies in search of a final form. A bad idea or a non-functioning attempt is instructive in figuring out how to move forward with a design.
At every stage, testing should be a foundational aspect of the design process. Testing to me looks like showing my work to others to see how they react, and putting it under external pressures. In the same way I stress-test my code, I open up my designs to criticism in order to find its weak spots early on. In my studios we had what we call "desk-crits" most weeks, where our professor directly critiqued our work. I openly welcome critical feedback in all the work I do as a way to bring my creations to their full potential.