Alright, we know what our problem is
, we have our team together
, it is time to start scoping out what our solution will look like. At Codebots, we follow a Design Thinking approach
when it comes to scoping, which has shaped our process into what it is today. Our scopes work through four stages: Understand, Observe, Ideate, and Prototype. Working as a team, we first diverge then converge through those four stages, doing our best to ensure that the solution which is built truly provides value to the users.
First off is Understand, which we covered in a previous article
. Next is Observe, which is the focus of this article. This stage concentrates on helping the Team understand the problem further by observing existing solutions and potential users, hence the name. It is the goal that by the end of this stage, the team will have a thorough understanding of both the problem and what solutions are currently out there trying to solve it. This can be done by using any number of activities from the Codebots Activity Kit
, but we chose to use User Interviews, Pattern Recognition and Secondary Research to achieve it for the Climate Action App.
This stage is particularly important for our team, because we didn't have a lot of experience working in the climate action space. It is vital that before we try to develop any sort of solution, we get a good idea of what will be involved.
There are two parts that we needed to gain a better understanding of going into this project: what is currently out there, and what are the technical requirements for building a carbon emissions calculator. How do we fill these knowledge gaps? Research.
Jack was given the task of researching all things technical. He looked at existing calculators, trying to discover where their data and calculations are sourced from. We did this in the hopes that we would be able to reverse engineer some of the data and calculations for our app. Jack also did some searching for open access APIs or databases which we could use as sources. Unfortunately, there isn't much out there, and all of the calculators we looked into were not forthcoming about how their calculations were quantified. We did find one excel spreadsheet which we were able to reverse engineer to start doing some initial tech spiking with, though our eventual partnership with Arete Sustainability did replace the need for that come development time.
Jay conducted research into existing calculators, though her research focused more on the user experience (UX) side of things. She looked at what sort of information the calculators collected, how they presented the results, and what sort of accuracy they achieved. From this, we were able to start forming an idea of what people may expect from our calculator and what design styles were effective for capturing the data.
The goal of our user interviews was to try to understand the different users of carbon emission calculators, and try to build a solution which delivers the most value to them. We interviewed owners of small/medium business who were interested in reducing their carbon footprint, but hadn't yet actually made any moves towards doing it; people who had previously gone through the process of calculating and reducing their footprint; and carbon calculator experts who could advise us on the solution.
Going into the interviews, we had a series of points that we wanted to make sure we addressed:
- what they would expect from a calculator;
- what sort of results they want to receive;
- what data they had access to for the calculations;
- what calculators they have already used; and
- what was driving them to go on this journey.
We interviewed many people and received fantastic results. The interviews gave us a wealth of knowledge, and greatly expanded our understanding of the problem. We were aware that there weren't really any calculators out there for small/medium businesses, but we were able to confirm our suspicions that there were many small and medium business owners who were keen to address their carbon footprint.
Not only was our idea validated, but we also got a good sense of what process and results they were expecting, along with what information that they had available to calculate with. This information means that we can ensure that our solution provides the most value to our users, and we aren't just blindly developing what we think will work.
When you combine all the information that we had gathered form our interviews and research, we ended up with a huge number of points to consider. We employed the Pattern Recognition activity to bring some sense to our data. The Pattern Recognition activity is used to help sort through findings and identify recurring themes and points to consider so that things can become more focused.
Normally, pattern finding is done in person, using post it notes and a whiteboard. However, we were all working in isolation so we had to get a bit creative. We ended up using Miro
(a fantastic tool) to simulate our whiteboards and post-it notes.
We put every key point from the interviews and research notes onto individual post it notes, then as a team we started grouping together similar ones. Doing this can be a fast and simple way of sorting your information and boiling it down to the key themes.
By taking the time to observe and understand our problem, we have now diverged from our problem and are ready to start honing in on what our solution may look like. Our team is stronger for having completed this Observe stage, because we now have a much greater understanding of what will be involved, what our users may expect, and how we can shape our app to provide maximum value. Next up, we will be converging in the Ideate phase and starting to plan out our solution.