Discovering the problem
Using empathy and prior knowledge, I begin by discovering pain points and delights in the user's flow. This time is used to create a User Journey Map to plan out a hypothesis for the project. I can gain a lot of insight by exercising empathy and figuring out what a user does, feels and thinks at every step of their interaction with the product. I'm also able to start writing down small ideas to the problems that are occurring on all levels of the user's involvement.
Defining the problem
I often need to assess what kind of information and data I need from participant. In doing this, I can insure that I'm using the right user research method. I usually start with surveys and interviews to broaden my domain knowledge and recognise any biases I may have a lot earlier. In the interviews, I'm able to dig a little bit deeper and find out if my hypothesis was correct. If I need to conduct any further research, I can use one of the many user research methods above. This process allows me to create user stories and a potential feature matrix for later use.
Depending on the domain knowledge, if I'm working on a new product, etc I may have to conduct a card sort to see if my assumptions of the information architecture match to the mental model of the users.
By now, we have our idea and we know as much as we can about how users will use, feel and think about the product. With that, we have enough information to start creating user flows. I currently use a combination of Sketch and InVision to create these.
Once we have come to an agreement on the flow, I'm able to start prototyping in a higher fidelity. This can be done through HTML, Principle, InVision; whatever is necessary to communicate the idea and see if it solves the problem at hand.
Testing and observing the prototype
Now I simply test to see if I have satisfied the questions that I used in defining the problem. This can be done through qualitative and quantitative tests such as session recordings, interviews, card sorting, heat maps, scroll maps, etc. The main thing is fitting the right test to the right question.
Outline successes and failures
By summarising my successes and failures, I'm able to more readily attempt the repeat cycle.
Take the failures and make them the new problem
In doing this, I am able to start the process again but with a much smaller and easier to handle scope.