Design thinking and the power of a prototype
%20(1).jpeg)
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:
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.
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.
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.
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.
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”.
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.
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.
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:
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.
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.
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.
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.
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.
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.
.jpeg)
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:
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.
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.
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.
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.
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”.
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.
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.
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:
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.
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.
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.
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.
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.
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.
