A few years back I was working on a project for a large organisation redesigning some of their legacy applications. It was the brief designers long for; the opportunity to shape the future UX of a whole family of web-based applications. The first app released would lay the foundations for the others to follow.

I didn’t waste time and immediately started researching the users to understand the existing software and worked with the product owner and various stakeholders to build a backlog of requirements the team could start working through.

After a couple of weeks armed with a much better understanding of the challenge at hand, we started workshops to shape the new product. In the meantime, the development team would start laying the essential foundations until we’d validated and detailed requirements and had at least a scribbled wireframe they could work with.

Fast forward a few months. We’d gone through sketches to wireframes, outlined user flows for the key user journeys, designed UI components along with detailed specifications and even had prototypes that demonstrated how we wanted things to work. We’d been out to customers to test the designs, received great feedback and everything appeared to be heading in the right direction.

There was one problem. We didn’t have anything built to release and what was built was a million miles away from something we could.

The problem described above isn’t uncommon. Time and time again we see teams creating designs that don’t get built or get built far from the intended design and experience.

This is fine for discovery or to validate a proof of concept but in a fast-moving industry, we need release products fast and frequently to stay ahead of the competition.

Over the past few years, I’ve adjusted my process in order to improve the product development process and wanted to share a few of the key changes which will hopefully help you and your team too.