All posts

Design thinking and the power of a prototype

Portrait of Steve Morland
April 29, 2022
5 min read
Author Steve Morland, sat at his desk, working at his computer with headphones on.

One of the most challenging parts of creating a new product is understanding the technical feasibility of your solution, how you test the viability of your idea and ultimately how you can overcome any development challenges as efficiently as possible.

A common approach to overcoming this is to test your product ideas through simulations or small samples of the intended final product. This is called prototyping and is one of the five stages of the design thinking process, an iterative methodology that teams use to understand potential users, challenge assumptions, and find creative solutions to project problems.

The design thinking process:

  1. Empathise
  2. Define
  3. Ideate
  4. Prototype
  5. Test

Traditionally the design thinking approach is adopted by user experience designers. However, at Leighton we have found this approach hugely useful when overcoming software development hurdles as well and regularly use it to streamline the whole development process.

Case study: Design thinking and prototyping in practice

A great example of how the team at Leighton have used this process previously in order to test out ideas and improve project outcomes was for a bespoke employee onboarding platform we created.

Our approach

The first three stages (empathise, define, ideate) were compressed down into one real-world physical meeting. Product stakeholders and technologists came together to work around the opportunity. It was determined that customers were already collecting a lot of data that with the right development could be of much more use to them. We felt there was a real opportunity to help our customers to unlock the value in that data.

Stage 1 – Empathise

We conducted research with our customer base to determine how they were already using our employee onboarding platform and what else would be beneficial to them. Research was gathered in advance of the meeting, as well as examples of how customers and users use the software.

Stage 2 – Define

The research and input from our customers was distilled down to help us clearly define their problems. Our resulting problem statement became that “customers wanted greater insight into their users ’experience”.

Stage 3 – Ideate

Using our problem statement and the examples of data collected we were able to work as a team to ideate solutions that would have the biggest impact on the problem. We brought together technologists, designers and account managers, who all bring very different solutions to the table based on their experience.

At the end of stage three, we had a clear “winning idea”. That idea was to mix the data with artificial intelligence (AI) and then package that development up into a service that would help our customers to understand their users better.

The prototype

Before any code was written we first had to nail down what we wanted to achieve with the prototype. This was summed up in a solution sketch which identified the goals, the unknowns, and the risks. From here we produced an application diagram with the understanding that this diagram would change throughout the prototyping stage.

A small team of technologists set about bringing the sketch to life which initially involved lots of pair programming. The authors of the sketch led this as they had the greatest understanding of the problem and solution, with other members of the team breaking away to solve self-contained problems as required.

The benefits of selecting serverless technologies

To prototype we chose an application that uses serverless technology.This can give teams all sorts of benefits but the main one is the speed of development. Serverless technology lets you concentrate on the code you need to write and not have to worry too much about the sourcing infrastructure. A team, like Leighton, that is experienced in serverless development can also take advantage of other benefits including:

  • The ability to develop full-stack features and release them to users quickly.
  • The fact that these projects work seamlessly with Agile product delivery.
  • The ability to get you to minimal viable product (MVP) more quickly.


For most applications, serverless is cheaper both in terms of the day-to-day running costs and in terms of reduced maintenance for infrastructure. For example, at Leighton most applications we have transitioned to serverless have led to a 10x reduction in running costs.

This type of technology is capable of operating on a massive scale, yet you only pay for what you use. This aligns extremely well with bringing a product to market as the cost of entry is so low, and as developers we know that we won’t have to re-develop and re-platform the application as it grows.

Utilising micro-services to aid faster development

Our solution was more than just a quick prototype, our experience with applications like this allowed us to create something that not only answered the problem definition but did so in a way that was technically elegant.

A micro-service architecture, which is an approach to software development that allows small independent services to communicate to achieve wider functionality, allowed several of our developers to work simultaneously on separate services, all crafting different parts of the same solution. For example. one worked on multi-tenancy and data capture, while another worked on data enrichment and analysis. This approach limits dependencies and allows for faster scaling.  

In this case we made use of AWS EventBridge to organise events in a way that would leave the bounded context that would ultimately become data that another service would have to consume and action.

Internally, within each micro-service, we utilised AWS Step Functions which allowed us to break down our business logic and ensure our serverless functions were only concerned with completing one specific task, for instance, one of our “steps” was to enrich a data record with some specific nodes that would be used for querying later on.

The outcomes

A clear picture of the challenges and where best to invest developer time

Through the prototyping week, we covered a lot of ground, and were able to focus our development on areas where we had to do more research. This would not have been possible without getting into the prototype.

A clear solution to the problem statement

At the end of the first week, we were able to illustrate exactly how we could answer the original problem statement. From here we were able to build a backlog of work to take the prototype forward and start testing with our customers.

An understanding of the return on investment

Our backlog allowed us to estimate the overall project cost more accurately, this was invaluable information as we knew how long it would take and what resources we needed to get the MVP to market.

What happened next?

We continued with the prototyping to make it more polished and then looked at not only how we could integrate it into our existing employee onboarding software but also at how we could offer it as a stand-alone service that any application could use.

Our UX team began to work on UX prototypes for the interface so we had a clear picture of what would and would not work on a technical level and to ensure easy use for customers.

We then started testing the development with existing customers who were using our employee onboarding software to validate the work we’d done and to give us a chance to gather any feedback that we could build into our product roadmap.

For more information about proof of concepts, prototyping and minimal viable products, click here.

Share this post
Portrait of Steve Morland
April 29, 2022
5 min read
All posts
Author Steve Morland, sat at his desk, working at his computer with headphones on.

Design thinking and the power of a prototype

One of the most challenging parts of creating a new product is understanding the technical feasibility of your solution, how you test the viability of your idea and ultimately how you can overcome any development challenges as efficiently as possible.

A common approach to overcoming this is to test your product ideas through simulations or small samples of the intended final product. This is called prototyping and is one of the five stages of the design thinking process, an iterative methodology that teams use to understand potential users, challenge assumptions, and find creative solutions to project problems.

The design thinking process:

  1. Empathise
  2. Define
  3. Ideate
  4. Prototype
  5. Test

Traditionally the design thinking approach is adopted by user experience designers. However, at Leighton we have found this approach hugely useful when overcoming software development hurdles as well and regularly use it to streamline the whole development process.

Case study: Design thinking and prototyping in practice

A great example of how the team at Leighton have used this process previously in order to test out ideas and improve project outcomes was for a bespoke employee onboarding platform we created.

Our approach

The first three stages (empathise, define, ideate) were compressed down into one real-world physical meeting. Product stakeholders and technologists came together to work around the opportunity. It was determined that customers were already collecting a lot of data that with the right development could be of much more use to them. We felt there was a real opportunity to help our customers to unlock the value in that data.

Stage 1 – Empathise

We conducted research with our customer base to determine how they were already using our employee onboarding platform and what else would be beneficial to them. Research was gathered in advance of the meeting, as well as examples of how customers and users use the software.

Stage 2 – Define

The research and input from our customers was distilled down to help us clearly define their problems. Our resulting problem statement became that “customers wanted greater insight into their users ’experience”.

Stage 3 – Ideate

Using our problem statement and the examples of data collected we were able to work as a team to ideate solutions that would have the biggest impact on the problem. We brought together technologists, designers and account managers, who all bring very different solutions to the table based on their experience.

At the end of stage three, we had a clear “winning idea”. That idea was to mix the data with artificial intelligence (AI) and then package that development up into a service that would help our customers to understand their users better.

The prototype

Before any code was written we first had to nail down what we wanted to achieve with the prototype. This was summed up in a solution sketch which identified the goals, the unknowns, and the risks. From here we produced an application diagram with the understanding that this diagram would change throughout the prototyping stage.

A small team of technologists set about bringing the sketch to life which initially involved lots of pair programming. The authors of the sketch led this as they had the greatest understanding of the problem and solution, with other members of the team breaking away to solve self-contained problems as required.

The benefits of selecting serverless technologies

To prototype we chose an application that uses serverless technology.This can give teams all sorts of benefits but the main one is the speed of development. Serverless technology lets you concentrate on the code you need to write and not have to worry too much about the sourcing infrastructure. A team, like Leighton, that is experienced in serverless development can also take advantage of other benefits including:

  • The ability to develop full-stack features and release them to users quickly.
  • The fact that these projects work seamlessly with Agile product delivery.
  • The ability to get you to minimal viable product (MVP) more quickly.


For most applications, serverless is cheaper both in terms of the day-to-day running costs and in terms of reduced maintenance for infrastructure. For example, at Leighton most applications we have transitioned to serverless have led to a 10x reduction in running costs.

This type of technology is capable of operating on a massive scale, yet you only pay for what you use. This aligns extremely well with bringing a product to market as the cost of entry is so low, and as developers we know that we won’t have to re-develop and re-platform the application as it grows.

Utilising micro-services to aid faster development

Our solution was more than just a quick prototype, our experience with applications like this allowed us to create something that not only answered the problem definition but did so in a way that was technically elegant.

A micro-service architecture, which is an approach to software development that allows small independent services to communicate to achieve wider functionality, allowed several of our developers to work simultaneously on separate services, all crafting different parts of the same solution. For example. one worked on multi-tenancy and data capture, while another worked on data enrichment and analysis. This approach limits dependencies and allows for faster scaling.  

In this case we made use of AWS EventBridge to organise events in a way that would leave the bounded context that would ultimately become data that another service would have to consume and action.

Internally, within each micro-service, we utilised AWS Step Functions which allowed us to break down our business logic and ensure our serverless functions were only concerned with completing one specific task, for instance, one of our “steps” was to enrich a data record with some specific nodes that would be used for querying later on.

The outcomes

A clear picture of the challenges and where best to invest developer time

Through the prototyping week, we covered a lot of ground, and were able to focus our development on areas where we had to do more research. This would not have been possible without getting into the prototype.

A clear solution to the problem statement

At the end of the first week, we were able to illustrate exactly how we could answer the original problem statement. From here we were able to build a backlog of work to take the prototype forward and start testing with our customers.

An understanding of the return on investment

Our backlog allowed us to estimate the overall project cost more accurately, this was invaluable information as we knew how long it would take and what resources we needed to get the MVP to market.

What happened next?

We continued with the prototyping to make it more polished and then looked at not only how we could integrate it into our existing employee onboarding software but also at how we could offer it as a stand-alone service that any application could use.

Our UX team began to work on UX prototypes for the interface so we had a clear picture of what would and would not work on a technical level and to ensure easy use for customers.

We then started testing the development with existing customers who were using our employee onboarding software to validate the work we’d done and to give us a chance to gather any feedback that we could build into our product roadmap.

For more information about proof of concepts, prototyping and minimal viable products, click here.

Watch now!

To watch the on-demand video, please enter your details below:
By completing this form, you provide your consent to our processing of your information in accordance with Leighton's privacy policy.

Thank you!

Use the button below to watch the video. By doing so, a separate browser window will open.
Watch now
Oops! Something went wrong while submitting the form.
All posts
Author Steve Morland, sat at his desk, working at his computer with headphones on.

Design thinking and the power of a prototype

One of the most challenging parts of creating a new product is understanding the technical feasibility of your solution, how you test the viability of your idea and ultimately how you can overcome any development challenges as efficiently as possible.

A common approach to overcoming this is to test your product ideas through simulations or small samples of the intended final product. This is called prototyping and is one of the five stages of the design thinking process, an iterative methodology that teams use to understand potential users, challenge assumptions, and find creative solutions to project problems.

The design thinking process:

  1. Empathise
  2. Define
  3. Ideate
  4. Prototype
  5. Test

Traditionally the design thinking approach is adopted by user experience designers. However, at Leighton we have found this approach hugely useful when overcoming software development hurdles as well and regularly use it to streamline the whole development process.

Case study: Design thinking and prototyping in practice

A great example of how the team at Leighton have used this process previously in order to test out ideas and improve project outcomes was for a bespoke employee onboarding platform we created.

Our approach

The first three stages (empathise, define, ideate) were compressed down into one real-world physical meeting. Product stakeholders and technologists came together to work around the opportunity. It was determined that customers were already collecting a lot of data that with the right development could be of much more use to them. We felt there was a real opportunity to help our customers to unlock the value in that data.

Stage 1 – Empathise

We conducted research with our customer base to determine how they were already using our employee onboarding platform and what else would be beneficial to them. Research was gathered in advance of the meeting, as well as examples of how customers and users use the software.

Stage 2 – Define

The research and input from our customers was distilled down to help us clearly define their problems. Our resulting problem statement became that “customers wanted greater insight into their users ’experience”.

Stage 3 – Ideate

Using our problem statement and the examples of data collected we were able to work as a team to ideate solutions that would have the biggest impact on the problem. We brought together technologists, designers and account managers, who all bring very different solutions to the table based on their experience.

At the end of stage three, we had a clear “winning idea”. That idea was to mix the data with artificial intelligence (AI) and then package that development up into a service that would help our customers to understand their users better.

The prototype

Before any code was written we first had to nail down what we wanted to achieve with the prototype. This was summed up in a solution sketch which identified the goals, the unknowns, and the risks. From here we produced an application diagram with the understanding that this diagram would change throughout the prototyping stage.

A small team of technologists set about bringing the sketch to life which initially involved lots of pair programming. The authors of the sketch led this as they had the greatest understanding of the problem and solution, with other members of the team breaking away to solve self-contained problems as required.

The benefits of selecting serverless technologies

To prototype we chose an application that uses serverless technology.This can give teams all sorts of benefits but the main one is the speed of development. Serverless technology lets you concentrate on the code you need to write and not have to worry too much about the sourcing infrastructure. A team, like Leighton, that is experienced in serverless development can also take advantage of other benefits including:

  • The ability to develop full-stack features and release them to users quickly.
  • The fact that these projects work seamlessly with Agile product delivery.
  • The ability to get you to minimal viable product (MVP) more quickly.


For most applications, serverless is cheaper both in terms of the day-to-day running costs and in terms of reduced maintenance for infrastructure. For example, at Leighton most applications we have transitioned to serverless have led to a 10x reduction in running costs.

This type of technology is capable of operating on a massive scale, yet you only pay for what you use. This aligns extremely well with bringing a product to market as the cost of entry is so low, and as developers we know that we won’t have to re-develop and re-platform the application as it grows.

Utilising micro-services to aid faster development

Our solution was more than just a quick prototype, our experience with applications like this allowed us to create something that not only answered the problem definition but did so in a way that was technically elegant.

A micro-service architecture, which is an approach to software development that allows small independent services to communicate to achieve wider functionality, allowed several of our developers to work simultaneously on separate services, all crafting different parts of the same solution. For example. one worked on multi-tenancy and data capture, while another worked on data enrichment and analysis. This approach limits dependencies and allows for faster scaling.  

In this case we made use of AWS EventBridge to organise events in a way that would leave the bounded context that would ultimately become data that another service would have to consume and action.

Internally, within each micro-service, we utilised AWS Step Functions which allowed us to break down our business logic and ensure our serverless functions were only concerned with completing one specific task, for instance, one of our “steps” was to enrich a data record with some specific nodes that would be used for querying later on.

The outcomes

A clear picture of the challenges and where best to invest developer time

Through the prototyping week, we covered a lot of ground, and were able to focus our development on areas where we had to do more research. This would not have been possible without getting into the prototype.

A clear solution to the problem statement

At the end of the first week, we were able to illustrate exactly how we could answer the original problem statement. From here we were able to build a backlog of work to take the prototype forward and start testing with our customers.

An understanding of the return on investment

Our backlog allowed us to estimate the overall project cost more accurately, this was invaluable information as we knew how long it would take and what resources we needed to get the MVP to market.

What happened next?

We continued with the prototyping to make it more polished and then looked at not only how we could integrate it into our existing employee onboarding software but also at how we could offer it as a stand-alone service that any application could use.

Our UX team began to work on UX prototypes for the interface so we had a clear picture of what would and would not work on a technical level and to ensure easy use for customers.

We then started testing the development with existing customers who were using our employee onboarding software to validate the work we’d done and to give us a chance to gather any feedback that we could build into our product roadmap.

For more information about proof of concepts, prototyping and minimal viable products, click here.

Download
To download the assets, please enter your details below:
By completing this form, you provide your consent to our processing of your information in accordance with Leighton's privacy policy.

Thank you!

Use the button below to download the file. By doing so, the file will open in a separate browser window.
Download now
Oops! Something went wrong while submitting the form.
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.