Our Timeline

The first steps

When we started with working on our first idea, the two of us were enthousiastic but directionless. An old question that everybody that started something has asked: "Where do you even begin?" We eventualy chose to start by speaking with a professor at our university. We asked a million questions about making a product.

September 2021

The Idea is Born

Before any coding and research could be done, we needed a solid idea. We desired to create something that was both a learning experience to us and a potential useful tool for others. That’s why the idea started at the ‘digital’ drawing board. It took us a handful of brainstorm sessions until the idea of an adverse impact centered app started to take form.

While bouncing ideas off eachother, we curiously started to seek through the internet. A calculator for adverse impact might not be the most ‘revolutionary’ idea but we found that most calculators on the web were pretty rudimentary in their output and crude in their look and feel. We saw an opportunity to make an app about the topic that reached further than ‘just being a crude calculator’:

The Adverse Impact App.

October 2021

The right framework

At this point in time we had settled on the idea of making a mobile app around the subject of Adverse Impact. Immediately we were confronted with a next decision. In what framework are we developing this app? Our experiences with coding and programming hadn’t really expanded to app building. So we started exploring the available options.

Eventually after some deliberation we decided to develop within Xamarin.Forms. We based our decision on the seemingly beginner friendliness and the option to simultaneously develop for Android and iPhone. We didn’t know it at that moment but the youtube channel of Gerald Versluis was going to be our guide through Xamarin.

Making the theory

The concept of Adverse Impact is not something we wanted to take lightly. If we were doing this then it was worth doing it right! That’s why when tackling the subject we decided that a robust body of research was important. Coming from our psychology backgrounds we wanted to take the extra step and not use something that has no evidence. We considered the theory the backbone of our app. That’s why we researched the topic and summarised it into a comprehensible document with cited sources.

November 2021

Learning the ropes

When we first started dipping our toes in actual programming our goals were related to “Learning the ropes” of Xamarin. It took us a lot of practice and revisiting of documentation before the first pages started to emerge. At the very beginning we experimented with different button styles, code-behind and logic.

Every new feature that we learned, helped us along with expanding our ideas for the app. At some point we even considered making a login page. This feature obviously did not survive as it was eventually deemed out of scope. It’s wild to look back at the very beginning of our app and almost not recognizing it when looking at the final design:

December 2021

Setting the scope

Our idea started very simple. We were going to take this formula used to get an indication for Adverse Impact and support it by researching the topic. This seemed straightforward until our minds started to work. Our ideas started to grow. We were excited every time we thought of a new feature. Our minds were overflowing with ways to expand our app.

This however also had a negative side. With the amount of additions we wanted to implement we saw our development roadmap becoming longer and longer. “Wouldn’t it be cool if…” was a sentence we used often. Our simple app risked to become bloated with features.

Luckily we caught this relatively early in the development. We had to concede that if we wanted to publish this app somewhere within a year of now we had to make decisions. What are we keeping and what are we scrapping? To separate importance we defined how our least viable product should look like. We learned an important lesson in defining the scope of a project.

January 2022

The many challenges

"Make a calculator for the formula of Adverse Impact."

On paper this sounds straightforward and in some ways it's true. Creating a calculator is a very popular beginner exercise for rookie programmers. However early into making the calculator we stumbled on many unforseen challenges.

One was related to the input an end-user could give. We needed to make sure that a user could only put numbers and strings where they were needed. For example they shouldn't be allowed to leave an entry field open!

Another thing was that we wanted to create a guided system for the input a user could give. How do make this calculator as obvious as possible for people that never encountered an odds ratio before?

Suffice to say we learned a very valuable lesson. When thinking about the end user a lot of things need to be considered.

Want to learn more about our coding journey?

Push the button below to see dive into the code!

Dive into the code

Building an app with multiple languages

We are native dutch speakers but we also wanted our app to be useable by an English speaking audience. To achieve this we started working with an app culture. Everything related to text got a key that related to both dutch and english translations within a ResXmanager. We are very happy with the end result however translating everything in two languages is something that shouldn't be underestimated.

February 2022

About UI

When the functionality of the app was slowely falling into place it was time to think about the User Interface. What was the look and feel we wanted for our app? We looked towards nature for inspiration. We really liked the idea of green and white. It invoked a young and fresh forestlike quality. We started to experiment with different combinations of green, white and grey. We eventually settled on a look. At that moment we thought the app had reached a final look. However later down the line we would tweak the look based on tester feedback.

To make a uniform look and feel throughout our app we created an app 'housestyle'. We created a lot of resources on the app level and made agreements when we were going to use a certain colour, font size, etc. in a specific situation. These agreements and resources were crucial for working effectivively together. These agreements were handy guidelines that allowed the sections that we worked on separately to feel like they belonged together.

March 2022

Our 'Least viable product' is completed

Somewhere mid to late march we had reached a point were most of the functionality we had planned was implemented. The app was nearing the state of completion that was needed for a least viable product. After another round of discussing we eventually decided that we were confident enough to start the testing phase of our app. Although we knew we weren’t done yet, we did savour this small victory.

April 2022

Preparing the testing phase

The start of April was also the start of our testing phase. Before during our development we tested our app both on our simulators and on our phones. However we knew that getting feedback from testers outside ourselves was going to be crucial. So we recruited friends and family that had access to an android phone and tasked them with following a checklist of functions we wanted them to tes outt. Our main message was clear: "TRY TO BREAK OUR APP”.

It might sound humorous but this allowed us to root out unknown bugs and gave us a insights into the general user experience. Besides this we also were very intrigued in the way our app would react on different phones. In the development phase we could only really test on the phones that we had readily available. Getting testers meant that we could expand the amount of devices the app could be tested on.

Our Testing Setup

Our testing needed to go as smoothly as possible. To ensure this the following structure was adapted:

1. Get our app on the google playstore and recieve testing links.

2. Ask our friends and family to become testers for our app

3. Wait (and hope) for the people to agree

4. Make a checklist of features we want them to 'try to break'

5. Send these instructions and the links to our testers

6. Wait for the testers to send feedback.

Down below you can find a snippit of our testing checklist!

May 2022

Testing the App

At the start of the testing phase we mainly waited. Our group of testers were composed of volunteers that each had their own busy schedule. We aimed to have at least 5 testers, as 5 are able to find at least 80% of usability problems. We ended contacting 8 testers.

Our plan was to give them a few weeks to allow them enough time to test our app. In this waiting period we didn’t completely fell inactive. There were still things to be done, so we decided to return to our written theory.

June 2022

Ending the testing phase

During the end of May we collected the feedback of our testers. When the final checklist with suggestions arrived we could start in earnest to improve the app based on their findings and experiences. In another meeting we decided to categorize their findings. Some aspects we anticipated, other aspects took us by suprise.

Reforging the app

The official final step in our testing phase was to implement the feedback:

Working on a great suggestion of one tester we decided to create a button hierachy within the app. With size and colour changing depending on the importance of the button.
A colour redesign toning down the brightness of the green to more softer colours.
The furter implementation of styles throughout the app and shifting these from page to app level.
A massive code cleanup.
And last but not least many bug fixes and corrections in spelling

July 2022

Contact with an expert

While working on our tester feedback, we also heard back from the expert we contacted. To our pleasant suprise, she wanted to see our project! This made both of us incredibly ecstatic and somewhat nervous. We did everything the weeks before our meeting to get our app and our written theory in the best state it could be. We were expecting a brutally honest opinion and hoped that it was at the very least kinda positive...

Augustus 2022

Implementing expert feedback

After talking with the expert in the field we decided to take a short and well deservered two week break. After this we jumped back in the project with the next steps we recieved:

One important feedback point we received from our meeting was that our app actually already did what it had to do. We had been playing with the idea to implement something that gives end users tools after they received their results. The feedback we received was that our app did enough by giving an indication.

We decided to implement a "What's next page?" In this section we providea suggestion to the end user to take their results from the app and contact a professional in the field. This allows them to decide if actions truly need to be taken. We also emphasized in the app that the results are a mere indication and should not be used to make important decisions without consulting a professional like a behavioral psychology expert.

Our app has reached it final stage but there still a few questions we need to answer

September 2022

The last steps

At this point our app was almost finished however we still needed to get some things in order before we could finally release. One was making a blog to share our learning experience and journey. For this we chose to go with WIX. It seemed very user friendly and allowed us, with no previous experience in website design, to make a good looking website.

October 2022

The legal side

One final hurdle we encountered was the legal side to making an app. We still had many questions about releasing an app:

Were there ways to protect our idea without having to pay large amount of money?
What about liability?
Are our current disclaimers enough?
What about our privacy policy?
In what extend could we use the word "Scientific"?

To answer these questions we first contacted Unizo. They already gave us very solid advice but there were still questions lingering. These were all answered when we booked an appointment with "de wetswinkel" literally translated to "Law shop". Here we recieved fantastic support that quelled our fears and answered all our legal queries.

November 2022

The final stretch

The complete month of November was dedicated to tying up all loose ends regarding the app. And documenting our complete journey in the blog.

The very beginning

The starting point of our timeline depends on the way we look at our journey. If we define the beginning as the moment our idea was born then our timeline should start in September 2021. However we believe it’s very important to also include our past attempts in our timeline.

Learning from failures

We already tried to bring an idea of ours into existence twice, and sadly we failed in both attempts. On one occasion the idea failed due to unexpected problems with legal rights and the other time our idea fell apart when we learned that it already existed in abundance. Luckily these mistakes were avoided by conducting market research at the beginning of every idea.

Even though we experienced these setbacks, it never discouraged us from trying again with something new. So it’s important to remember:

"We didn't fail once... We failed twice!"

A collaborative workspace

The two of us live a considerable distance apart from eachother. If we wanted to effectively work together, then we needed an online space that made this possible. We found this in a digital whiteboard named “Miro”.

This tool allowed us to visualize our brainstorming sessions with mock-up’s, flows and other notes. We also used the tool asynchronous to list links, ideas and to do’s that the other person could eventually look through at their own leisure. In the end collaborating through the medium of the online whiteboard was much more convenient and straightforward .

Coding 101

Once the framework was selected, we naturally came to the part of learning to work with it. Xamarin.Forms is written in XAML and C#. These were new languages for us. Every coding language has their own style and quirks which meant that we had to start somewhat back at the start of the learning curve. Although we knew that a lot of practice still needed to be done, it didn’t dissuade us. We were motivated and eager to master, or at least to become somewhat competent, in these languages.

Our self-study comprised of watching tutorials and reading through documentation. At a certain point we decided to buy a course on Udemy to obtain more structured learning. Little by little we gained proficiency. We learned concepts such as code-behind, working with global variables and how to navigate pages. Every step was neccesary to create the app.

Logic in the madness

Eventually we reached a point where our insight in Xamarin and C# was good enough to start visualising our app structure. We needed a logic in the chaos of our app. This logic had to be something the end user could quickly understand and easily navigate through. We returned to our digital drawing board and started connecting the navigation flow of our app. Eventually after a few lengthy discussions and drawing dots between parts we settled on the following 5 destinct sections:

Our hubpage
The Calculator
An E-learning page
A theory page
An 'other' page that would serve as a bucket for smaller pages such as the disclaimer.

Keeping in scope

We had to ask ourselves a hard but important question:

We could have implemented ideas until our hair turned grey, but from the very beginning we agreed that this app will be a learning experience. We didn’t want to wait years to release. We needed to play timekeeper to get release it in the near future. Everything that worked towards the release was kept, and everything that seemed too far removed was dropped. In a famours term used by writers: “We killed our darlings.”

"Do we want to implement this feature because it’s core to the experience or is it something we think is cool but in reality not essential?”

Accepting our skill limitations

The way we were going to represent our theory changed a lot in concept aswell. At first we merely wanted to get our information into a PDF that users could consult. Two things changed in this regard.

Firstly we wanted to have something besides our theory that at this point was just long text form. Something bitesize that could explain a layman the basic concepts without having to read the entire theory. We tried to make an entire E-learning system with different exercises, branching paths and feedback, however we soon decided this was out of scope for the project. We didn’t completely abandoned the idea though and incorporate the concept into smaller, less technical information pages.

The second change was abandoning the pdf viewer idea. The reason for this was the limitations of our skills. Making a viewer for pdf was too technical for the scope of our app and meant we would need to wait a significant longer time. Eventually we needed to make the decision to abandon the pdf viewer in favor for a theory page.

A new homepage

While thinking about our general UI, we also thought it was the perfect moment to give a facelift to our homepage. We knew we wanted a colourful, stylish and lush frontpage while keeping a sense of simplicity. We also decided to work with reverse colours idea within our pages. The front page would be mainly green with white accents, the other pages were switched to be mainly white with green accents.

The style for the hubpage was very much achieved through trial and error. Some of things we did were testing different gradients, playing with button sizes, putting different buttons on different backgrounds, using different icons, and the list goes on. Eventually we settled on the light green gradient background, with four large equally big buttons.

Want to see how the homepage evolved?

Push the button below and see for yourself!

See the evolution

The App store

The first step before any testing could be done was finding a way to get our app distributed to our testers. This meant that our app needed to be on the Google playstore. The playstore allows for testing versions of apps to be distributed. To get on the playstore we paid a one time fee for a developer account and after that most of the following steps were quite easy.

That was until we encountered a small roadblock: An app on the playstore needs a privacy policy. Although it seems so obvious now, we didn't really think we were going to need one at this point in our project. Especially because we hadn’t released yet and our app doesn’t really gather that much user information. However it needed to be done so we searched for templates and wrote up a privacy policy.

With this done we finally made it to the store.

A valid question you may ask yourself is probably: "Why didn't you guys make this for IOS?". It's true that Xamarin.forms allows for simultaneously development for Android and IOS. However the cost of IOS development is much higher. We would need both a mac and an Iphone which none of us really have. We also would need to pay for a developer account which is 99 euro for a year. (Comparison: Android has a once in a lifetime payment of 25 euro). This seemed like a big investment which lead to the decision to only release it for android.

Revising the theory

We decided to reread our theory and polish it. We thought it would be interesting to try and contact an expert in the field of Adverse Impact. The first person that came into our minds was the professor that taught us about the concept. However we didn’t want to come to her with a shoddy theory. We decided to read and revisited our theory many times over and polish it were needed.

A second opinion of someone in the field could help us find the flaws and shortcomings in our current work. Especially because we didn't want to be snake oil salesmen or charlatans. We decided to send a very respectfull mail and hope that the professor was willing to give two alumni with an idea the time of day.

Implementing tester feedback

The importance of the testing phase couldn't be overstated.

Below is a small list of things our testers encountered:

Bugs connected to diferent screensizes.
Text that was hard to read because of size and colour
Unappealing colour on certain pages.
Distortion of pages due to landscape mode.
Spelling mistakes
The non-existence of a button hierarchy
A myriad of smaller bugs

A fantastic meeting

The day of our meeting had arrived. We were both dressed in a fine shirt and ready to accept whatever opinion we were going to get. As we arrived at the university of Ghent our nerves were on edge.

However the conversation we had with our professor went great. We got a lot of valuable feedback and our idea seemed to have some merit. We ended up having a fantastic conversation about the topic and next steps. Reassured and encouraged we left the university with our heads held high. The end of this journey was slowly approaching

Deciding to launch

Our meeting with the expert was a pivotal moment for our project. We had a contingency plan for every possible scenario:

Scenario 1: The feedback is negative

We don't release the app. It's mainly seen as learning experience and we move on to the next project to avoid a sunken cost fallacy.

Scenario 2: The feedback is positive

We release the app and go the extra mile. We take time to polish it with the feedback and summarize our journey with a blog.

Full release