My process for most projects
I'll spare you the photos of post-its on a wall.
Hint: I'm not the dog.
I use the steps below for most of my in-house and client projects.

This does differ depending on the type of project, but hopefully gives you an idea of what I think is effective.
You'll may have noticed that my portfolio does not have detail on all of the steps below: as I'm only including the interesting parts, to save us all some time from reading the same sort of thing over and over.
A. Understand & empathise
Don't ask "what are we building next?", but instead ask "why are we doing this?".

This puts the focus on the target audience, and allows better understanding of what their problems actually are.

Talk to the actual people that might have the problem, as well as research the area to gather as much information as possible.
B. Define
Define the usability problem.

Assimilate all of the research and information gathered, and synthesise into the core problems.

A clear way achieving a common understanding with these problems is user stories: define who the problem affects, what happens if the problem was not solved, where the problem is taking place, when the problem needs to be fixed, and why it is important for the problem to be fixed.

For example a short problem statement: "As a [persona], I want to [do/have something] so that [reason]."

Use these problem statements to then define personas, and pick scenarios to focus the design around.
C. Concept & ideate
Generate concepts with the ultimate goal of creating a better overall product for the end-user.

One fun way to start ideating is to create an advert for the ultimate vision. This can help you work backwards to today from that idea.

Take the human-centred problem statements and ideate around new solutions with alternative ways of tackling the issue. Some of my favourite ideation techniques include: Worst idea in the room, SCAMPER, Six hats, wishful thinking, and simply questioning assumptions.

Map out the user flows, simple sketches and storyboarding help illustrate the concept work best here.
D. Prototype
Build prototypes of a few options.

Depending on fidelity required prototypes can range from simple screen mockups to coded test apps, to quick hardware prototypes using interfaces like Arduino.

Investigate each prototype and see how they address the problems identified. Be proud of the design, and only then begin to iterate and test (deadlines permitting).

Will start to get a better idea of the constraints, and a clearer view on how real users would think, feel and behave when using the product.

Prototypes could start to consider the developers needs, and how the data might need to be structured and implemented.
E. Test
Test the prototypes with real people and users.

Get quantifiable data through ranking and A/B tests, as well as subjective notes with remarks and feedback.

Then analyse this user feedback for further iterations. Depending on this, the problems may be redefined to help inform the understanding of the users, and this will cause a few loops between the steps such as going back to C.
F. Production
Depending on the project type, there may be the handoff and managing of the product with developers or manufacturing.

This may include a feedback loop with the devs for further refinement of the designs, as well as exporting of the assets.

Or implementing feedback from manufacturers to optimise the hardware designs, and ensure proper delivery of the product.
Please get in touch for more details on a particular example, or if you have any questions.