GEOSOLAR

15 min readJan 28, 2021

This project was part of the Digital Shaper Program hosted by Techlabs Copenhagen in autumn semester 2020/2021.

INTRODUCTION

Geosolar contributes to a more sustainable future by helping people understand the costs and benefits of installing solar panels on their roofs. On our website people can enter their home location and average monthly energy consumption and based on that they receive the solar energy potential for their house. This includes a calculation of when they will break even and how much space the panels will take up on the roof. On top of that, the website provides some basic information on how solar panels work. The website was created based on the findings from preliminary UX research and coded in Python (BE), as well as HTML, CSS and JavaScript (FE/BE).

METHODOLOGY

User Experience Methodology

In this project, we utilized user-centered methods from the early stages of the project when we were brainstorming on how our solution would look, up until the final stages of creating a medium-fidelity prototype to help the web developers with an idea of the layout and flow of the website. Subsequently, the UX team members carried out usability tests of the website with potential users. It was important to use user experience methods to ensure that the solution is designed in the optimal way for the potential customers.

User stories

We began our research by coming up with user stories, which enabled us to understand the perspective of our potential users. We assumed that the main user group for our website, at least at the beginning, will be private users willing to install solar panels in their homes. The initial thought was that this kind of user is budget-oriented, as he wants to install solar panels due to the savings they shall bring. On the other hand, we also saw potential in addressing our website to companies that install solar panels. It would give them a possibility to present their products on our website and increase the user base. What is more, our project would provide them with data on solar power potential within specific regions. Eventually, the GeoSolar website would enable to match end-users with companies, which would benefit both groups.

Since user stories were a strong help in terms of planning our future website, the whole team participated in the brainstorming session and narrowed down the user stories as follows:

Who

What

Why

Budget oriented homeowner

where & how to install SP

being sustainable by reducing greenhouse gas

increase my property value

Solar panel installation company

reasonably priced but efficient

Data on solar strong regions

brand perception

pay off solar panel investment

energy efficiency

increased customer base

Rich picture

Since we already agreed that our target user groups shall be private users and solar panels companies, we had to consider the relationships between them and the website, as well as other potential influences. We thought that the rich picture will allow us to understand those better and to present them in an approachable way. Thus, the main interest for our website is an end-user who is interested in installing solar panels. However, he is concerned whether it even makes sense for him to invest in those if he lives in Denmark, where the amount of sun is not that significant. He is also wondering how much money he will be able to save. Further, he is interested in knowing what are the costs he needs to bear in mind when installing solar panels. On the other hand, he will certainly need to find a trusted company that would install his product. The initial idea of the project was to link users to such companies through GeoSolar website. The companies would provide us with their data and product information, so people using our website could easily go through their assortment and contact them if needed. At the same time, the GeoSolar project could use its potential in also linking users to the government’s support and information about tax returns. Danish government does offer support for people using solar energy, and therefore all that information could be easily available on our website and linked to the government’s page. It would allow people to be more informed and possibly encourage them to use solar energy.

How might we — Method

Finally, after establishing target user groups and understanding relations and connections between them, it was time for us to think about what are the main features that our website should have so the established relations are supported. In order to do so, we used the ‘How Might We’ method and came up with the following ideas:

How might we… make it easy for users to understand the benefits of solar energy?

How might we… provide location-potential information and solar panel prices in an integrated way to support end-users in decision making?

How might we… support solar panel companies in target marketing?

How might we… connect potential users with solar panel companies?

Using the ‘How Might We’ method prepared us better to think of how our website might actually look like and what tools it should include. What is more, we did some ‘competitors’ research, where we tried to find some websites and projects having similar purpose to ours. It gave us the idea of what we might implement now or as a future development.

Low fidelity prototype & User feedback

In the project, we create a low-fidelity prototype after defining the user’s needs and confirming features from the data science team. Olsson et al (2017) defined a low-fidelity prototype as a prototype “Produced in a form that is different from the final product”. Eg. paper sketches. We created paper sketches of the landing page as can be seen in the image below.

It was important to start with a low-fidelity design as it helped the UX team put down their ideas and confirm with the web developer and data science team that was the solution they envisioned. We followed the affordances of current websites which have a top navigation bar that allowed users to know what potential actions can be taken on the website. Once the team approved the prototype, we asked potential users for fundamental feedback on the design. Users said the tabs on the right corner made sense but wanted to know what the map at the bottom of the page would do. This would become clearer in the medium-fidelity prototype. The users suggested including affiliate partnerships with solar panel companies and information on government schemes that benefit individuals who create and use solar energy.

Medium-fidelity prototype

Subsequently, we create a medium-fidelity prototype considering the feedback we received from our mentor and potential users. This digital prototype was created using the cloud-based design tool, Figma. The tool allowed for strong collaboration as both the UX designers could create the prototype simultaneously. Additionally, other team members could view the design and leave comments on specific parts of the design. This allowed for seamless collaboration between the team.

Our digital prototype was a medium-fidelity prototype as Olsson et al (2017) defined it as a prototype that “ Could be in a computerized form but with a few of the functionalities of the final product”. We focused on the form of the website that would help our web developer design the final site. The three pages of the website can be seen below.

The functions were limited as the data science team was in the phase of creating the savings calculator and so we felt it was best to create a few functions in the current stage.

Testing the solution

We tested the solution with the users by using the web site created by the web developer based on our medium-fidelity prototype. The UX team created a testing guide with a list of 5 questions to ask potential users. In this testing, the UX designers wanted to test the usability and intuitiveness of the design but also check if the purpose of the website was clearly interpreted by the potential users. Additionally, we asked the users to clarify what they understood from the labels and terms used on the site.

Data Science Methodology

As learned in Techlab’s Data Science track, we used Python for the preprocessing of the dataset and creation of the API connection. Here, we mainly made use of the Pandas library for manipulating, rearranging and cleaning our core dataset (sunshineHoursDatabase). We further used pandas foundations to create new data frames (household_Database & panel_prices). In our case, it was necessary to include some arithmetics to do the break-even calculation and build an API to connect the data backend side with the front end side of the website. Most of the coding has been done in a Python Jupyter Notebook. However, for building the API we used Azure Functions in Visual Studio Code to do proper debugging and write the code in one go. The steps taken for the data preprocessing and creation of the API will be elaborated on the upcoming sections.

Data Sourcing & Cleaning

We based our project on two databases. The first one — the monthly distribution of sunlight hours across 98 Danish municipalities — was acquired through our mentor Nicolai. It required heavy data-cleansing in order to make data easily accessible and extractable. We transformed a multiple-sheet excel file into a 3-column data frame indexed by municipality and month and displaying sunlight exposure in the last column. The second database — price, productivity and parameters of solar panels — was created from scratch using Python-based on information acquired from different sources online such as electricity price comparison websites such as Verivox and by reaching out to danish solar panel providers. Both databases were crucial for the backend of the project — the calculations of break-even utilized both of them.

Data Storage

Since this was a very small project and we did not want to run any database on a server, we had the option to store the datasets as an Azure database. However, after starting to build the API and transforming our datasets into JSON files we revisited the process and realized that the small size of our datasets (20KB, 73bytes and 70 bytes) gives us an even easier option for storing and accessing the data. Hence, for simplicity reasons, we decided to store the objects of our data frames as key-value pairs in a dictionary within our API code. Since we used Azure Functions in Visual Studio Code, this came in very handy as it allowed us to create a serverless API, implement a RESTful architecture and safely store the information therein. This way we immensely simplified and sped up the creation of our API code.

The API Code

The two main challenges of the API code were:

Connecting the user input (frontend) with our API code and the breakeven calculation (backend)
Writing the code for the breakeven calculation

The API code was written in collaboration with the web developer and after some debugging, we were able to put the calculations together and connect them to the front-end. The following picture shows the first few lines of our API code:

We made a get method with three parameters:

The user’s municipality
The user’s energy consumption
The user’s household size

Here we make an http-request to our api in the browser:

The HTTP function uses the GET method to get the parameters from the front-end, which were specified. This is how we access these in the code:

Our sunshine “database” is stored as a dictionary with the key/value pairs being the kommune the user lives in (key) and the total hours of sunshine that kommune gets in a year (value). Our second “database” (householdDatabase) is also stored as a dictionary in line 117 and consists of the number of people living in one household (key) and their average electricity consumption (value).

With an if / else function the code differentiates between two cases:

The user does know his / her electricity consumption → Breakeven is calculated with that value. If the user does not enter energy consumption, the front-end sends a “na” as a placeholder, so the API uses the household instead
The user doesn’t know his & her electricity consumption → Code looks up the average value from householdDatabase and uses this value for the breakeven calculation

Example of an elif function, that calculates the break-even when the user enters a household size lower than 3.5 (here: SystemSize):

In the following section, the API will be more elaborated on from the web developer’s side in terms of connecting the front-end.

Web Development Methodology

The webdev was mostly done in the final part of the development phase and written in Visual Studio Code with HTML, CSS and JavaScript. Through a multi-methodical approach of observing and testing (the alert method being the favourite), we successfully established a connection between backend and frontend. Due to time constraints and having only one web developer, we prioritized the functionality of the calculator rather than the aesthetics of the web interface, which left the front-end with a few design shortcomings.

We employed a two-tier architecture that enabled us to hide our business logic and data from the front-end, making it only accessible via the API. Using a PaaS model, we employed Azure and the cloud service Netflify to do so. In order to allow the API to access the resources from the webpage and vice versa (and adhere to CORS principles) we created a function app on Azure and added the front-server (Netlify URL) as a trustworthy origin. What came in handy was that we could connect Netflify with our Git repository, which provided continuous integration and deployment.

Front-End

For the front-end, we downloaded a bootstrap design-template in a blog format that already came with a few interface-components. As this template used an MIT license, we were good in terms of using it for the purpose of this project. In the initial design-phase, the template was complemented with components based on the UX designer’s prototype.

We added basic placeholders and royalty-free pictures from pixabay to create a static webpage. Later on, the content was added by a combination of bootstrap’s grid-system and cards. Initially, the plan was to have a search field (for the municipality) and a map of Denmark on the landing page, which the user could hover over to see the sunshine hours in their respective area. We did have a search field but this was later used to complement the calculator. However, the map was not feasible and pre-made components for a functionality like this were exceptionally expensive.

The Savings Calculator

As described in the introduction, the user has three input fields: Energy consumption, household size and a search-field with a dropdown function for municipalities. The front-end makes an HTTP get request when the submit button is clicked.

What followed was coding the validation of user input, so that upon entering an invalid value, or no values at all, a warning will be triggered and no HTTP call will be made. Upon successful input, the API will send back the calculated numbers. If the request was not successful, the user will be informed that “the API didn’t like your request” ;)

Back-End

We created two API’s — the first one (httptrigger4) containing our calculations and the second one (httptrigger3) for the third user input field. This API simply contains an array with the municipalities and a response body to the HTTP call, which is a JSON with a string-key called kommuner (line 12). This pulls the data out of the array and enables our users to search for their municipality in the drop-down search-field.

We used the fetch API to connect the front-end with the API. For the dropdown-box, we looked for a suitable select box, which we found on select2. Through trial and error and using the alert method to test the code, we managed to find the right function that can make the API call, as well as store the corresponding values in the cards.

PROJECT RESULTS

We managed to set up a website that gives an individual living in Denmark first, basic information under our ‘Solar Panel 101’ tab about what he/she needs to consider when getting solar panels. Second, under ‘Savings Calculator’ he/she can enter the municipality he/she lives in and its energy consumption. Here, the user has the option to either enter its yearly energy consumption in kWh/year or simply enter his household size (from 1 to 5). As a result, based on the setup calculations, the user will know how big or small the solar panels must be for his/her energy needs and also get a breakeven calculation on when he/she will break even after making the investment of buying solar panels.

Unfortunately, something went wrong on the back-end side, so a warning message is triggered when the user enters an energy consumption of less than 800. This may have to do with the code prioritizing the average consumption from the household database, instead of using the user input. While we tried to account for this in our code, we haven’t figured out the reason for this malheur yet.

The website can be accessed under the following link: https://geosolar.netlify.app/index.html

FUTURE DEVELOPMENTS

In terms of UX design, the team would like to test the design of the website with a larger sample to gain some statistically relevant results. Alternatively, it would be insightful to carry out focus groups to test the design. Focus groups can be useful to measure user reactions and analyze the interaction between users and the design.

Another development in the website could be providing users with information on government schemes or support based on the area code they enter. This was currently out of scope in the project due to the lack of time.

Due to time constraints, the Data Science & Web Dev team did not manage to add solar panel providers and solar panel models and prices to the website. This would give the individuals interested in getting solar panels an even better starting point as danish solar panel providers are nowhere gathered together and most of the time prices and further information are only accessible by reaching out to them directly. This is why we see even more potential in extending the website by adding this information. Doing that, we imagine creating affiliate partnerships with the solar panel providers, where both sides generate a benefit.

CONCLUSION AND LEARNING

UX-wise, we strongly believe that thanks to conducting this project we gained lots of hands-on experience with the design process. First, we learned the user experience design, mindset and principles, which enabled us to be more creative and to approach the project from various angles. From the Data Science and Web Development perspective, we learned how much love has to be put on details of the code and how important it is to communicate with each other to carve out the best option for the back- and front-end to communicate.

What is more, working on GeoSolar taught us how to work in a multi-disciplinary team. The whole team had to closely cooperate with each other, in our case, UX Designers with the Web Development team, as well as with Data Science, in order to obtain a coherent final product. Even though each team was so different, we learned to communicate effectively. It enabled us to work together more smoothly but also to understand each other’s perspectives, especially in relation to the possibilities and limitations of the project. Finally, thanks to constantly testing our prototypes with users, we learned how to put a user-centered approach towards design into a real-life situation. We had to establish criteria for a relevant group of people to research, we had to understand their point of view and try to design a product that would suit their needs best. Further, we gained hands-on experience with Figma, Python, CSS and Javascript, which are tools used in many companies around the world. We believe the hands-on approach was an excellent addition to the online courses and gave us a solid foundation for further development.