How we delivered the Africa Climate Summit mobile apps in ~6 weeks

I recently had the opportunity to lead the team that worked on the tech that supported the inaugural Africa Climate Summit (#ACS23). This was made possible by Bayes Consultants, the team that worked on the tech for the Summit. As the product strategist, I ensured we delivered one app and two web platforms for different audiences with a timeline of just about six weeks. This post will focus on how we designed, developed, and launched the Africa Climate Summit (ACS) mobile application.

Important note: the post focuses on our work as the tech team. We didn’t have any input into the execution of the event beyond the touchpoints affecting the application.

The task at hand

Technology was a critical piece for the just concluded Africa Climate Summit. We had three workstreams.

1. Develop a mobile app available on Android and iOS that will act as a companion for Summit attendees. This app was only available to summit delegates. The delegates logged in using credentials shared with the email they registered with. (Google Play& AppStore)
2. Develop a platform that would match project developers in the climate space to potential funders and providers of technical assistance — ACS Virtual Dealroom.
3. Leverage a Large Language Model (LLM) like GPT to provide a web platform, allowing the team to get insights from the documents they added using a chat system. (Not publicly available).

In this post, I will focus on how we delivered the mobile application used by 12K+ summit participants. The app supported three conferences: the Africa Climate Summit, Africa Climate Week, and Africa Youth Climate Assembly. It was available in six languages — English, French, Kiswahili, Portuguese, Amharic, and Arabic. Using the app, Summit attendees could build their itinerary of events, browse through all events, and see vendors and exhibitors at the Summit, to name a few.

A screen grab of how the app appears based on your chosen language. The news feed showed all content (irrespective of the language), while the event section showed already translated content. Interestingly, Arabic’s orientation changes from left to right to right to left.

I did a short walkthrough video, which you can view here on LinkedIn.

In another post, I will delve into my learnings from our LLM work.

Why did I take on this?

I knew this would be an immense challenge, and we would need more time to deliver on everything. I still took on it because of three key reasons.

1. The intersection of climate and AI was appealing to me. I already had an interest in both, and I was unwilling to forego getting an opportunity to work on this.
2. To prove a point to myself — after I was affected by the layoffs at Microsoft (I wrote about my lessons from my stint at Microsoft), I needed something to remind me that I am good at what I do.
3. Who doesn’t love a good challenge? This was something I would remember years later.

In hindsight, we almost bit more than we could chew. We still delivered on the three workstreams, but it came at a cost. The team worked late into the night almost every day, especially the last three weeks. Will I do this again? Not with the level of pressure we had, but I am proud of what we achieved.

How we delivered the mobile app

We had just about six weeks to work on the three projects. To meet the aggressive timeline, we created three separate teams with some shared resources across the teams. The shared resources included me as the product strategist, our scrum master Bethuel Muthangya, Bayes CEO Brian Nyangena, Bayes tech lead Ian Mutai, the front-end development lead Felix Mokua, DevOps, QA, and security.

As a big advocate of the human-centered design process, we chose the Double Diamond design process to execute the project. Due to our time constraints, the process was a heavily stripped-down version.

The Double Diamond Design process (Image courtesy of https://uxdesign.cc/)

Discovery

The goal of the discovery phase is to develop a clear and shared understanding of the problem across the team and other key stakeholders. Impactful innovations or solutions start with a good understanding of the problem, as a solution can only be impactful if it is solving the right problem.

Rephrasing the ToR

We used the ToR as our guide, focusing on understanding our key personas and their needs. We considered all personas, including attendees, speakers, vendors, and exhibitors, outlining their problems, goals, proposed solutions, and deliverables. To demonstrate our approach, this is what we did for summit attendees.

• The problem — For summit attendees, navigating through a massive event like the Summit is generally tricky. There are multiple events of different types in different locations at different times.
• Goal — provide a summit companion for the inaugural edition, allowing delegates to find what they need when needed.
• Solution — Provide information about the Summit, the ability to discover and pre-book sessions they are interested in, find vendors and exhibitors, and navigate through the event (using smart beacons)
• Approach — this was a step-by-step outline of how the app would work, starting from how users will be onboarded and what content will be on the app.
• Deliverables — iOS and Android apps. We had a progressive web app (PWA)as the backup in case we didn’t get one or both apps not approved on the store on time.

We did this exercise for each of the personas.

Customer journey mapping

The next step in our hurried process was developing customer journey maps for each persona. In most cases, I would have this activity in the define section of the process, but we had too many unknowns for it to be helpful there. Instead, it served as a better way for us to understand our users.

Customer journey maps visually depict customers’ end-to-end experiences when interacting with a product, service, or brand. They outline touchpoints, emotions, and actions at various stages. These maps help businesses gain insights into customer needs, pain points, and preferences, facilitating user-centered strategies, products, and services.

Customer journey maps capture users’ full interaction with your product, including external thoughts & interactions. Image courtesy of Delighted

After the mapping exercise, we could describe the users and context holistically.

From this exercise, we had the following main outputs.

1. A revised ToR with a focus on the problems we are solving
2. A customer journey map for each of the personas
3. A design kick-off document outlining — Project objectives, Approach, Key activities and deliverables, Project team & roles, Coordination and collaboration, and Risks & mitigations. In a separate post, I will discuss why this document is critical to project success.

Definition

The definition stage in the double diamond design process is probably one of my most exciting phases. This is where we bring to life the ideas we come up with. From the previous step, we came out with a very good understanding of the problems faced by our users, and from the customer journey mapping exercise, we developed a decent understanding of the features to ship.

In this stage, we focused on narrowing down the app experience and the step-by-step process users would go through to utilize the features.

Step 1: Low fidelity wireframes

Low-fidelity wireframes are a quick way to bring your flow to life and reduce changes in later stages. This exercise involved the UX/UI designer, the front-end lead, Bayes’ Tech lead, Bayes CEO, our scrum master, and me. Over two days, we worked on the detailed flows for each user journey.

The low-fidelity sketches of the events feature on the app. I added the wireframes to Figma with comments to provide our UX/UI designer context.

This step allowed us to validate our ideas quickly, cheaply, and collaboratively.

High fidelity designs

Our UX/UI designer, Eric Asiago, led the next step, translating the low-fidelity wireframes to UI screens. Upon completing a journey, with the help of our front-end lead, Felix Mokua, we reviewed it and gave him feedback. We had two sets of Figma files to speed up the review process. One was shared between us, i.e., me, Asiago, and Felix. The other file was available to anyone on the project. Asiago would update the ‘public’ version once we had gone through our 3-person review. The other reviewers were the tech lead Ian Mutai, the CEO Brian Nyangena, and Bayes COO Evans Kayo, who has an impeccable eye for design.

The final-final-final version of the landing page. We made a few tweaks later.

To speed up the review process, Asiago would share the designs a day before, and I would plan a design review meeting for the next day. This helped us cycle through various iterations quickly, saving the project time. Additionally, the development team didn’t wait for all the designs to be completed to start their work.

Develop

A big source of pressure for me during this project was that we had a dev team in place early. They were all waiting for me to guide them on what we were building!

We had a front-end and a back-end team that worked separately for the assignment. As the product lead, my job was to bridge the two with support from my scrum master, Bethuel Muthangya. I worked closely with Ian Mutai (Bayes Tech Lead) and Solomon Maithya (Senior Developer) on the dev side.

It was tempting to dive right into development, but from experience, I know this usually backfires. Making changes further down the process is quite expensive. We used the following approach to unblock the developers early on.

1. We were confident the low-fidelity wireframes would closely reflect the final design. The developers started working on the architecture and database schema using low-fidelity wireframes and user stories.
2. We developed user stories for each feature and user journey to capture the elements not explicitly communicated by the designs. We added the user stories to Jira, the project management tool we chose.
3. During the UI design phase, we prioritized unblocking developers by focusing on the user journeys in the order they would implement. As an example, we finished onboarding first and did the events next.

I strongly believe in using design and development processes as they offer a repeatable and scalable approach to executing projects. For this project, we chose the agile software development process. We made a couple of tweaks to suit the project constraints but mostly retained the standard process.

1. Sprints ran over just a week with a demo every Friday. Later in the development process, we invited the ACS team to the demos but didn’t change how we did them.
2. We used Jira to track all project activities. Initially, this was a challenge, but as the team got used to the workflow, it got easier.
3. We had daily standups that ran for 15 minutes. Before the standup, all sprint participants responded to Standuply, a Slack standup bot. During the call, we focused on blockers. Many days, the standup only lasted 5–7 minutes. Initially, team members were not very forthcoming with listing out blockers, but a week into it, this issue disappeared.
4. To ease communication, we used Slack.
5. We had most of the technical and design discussions separate from the standup. I encouraged team members to set up meetings to do this and loop in the required actors.
6. Our QA team was a critical part of the puzzle as we had a very short time to build and ship features. The team worked hand in hand with engineering to test and document bugs. We relied on their go-ahead to make the call to go live.

The development team navigated this phase very well despite the short timeline and changes in scope. We tried to limit changes later in the process, but for anyone Summits shipped a digital product, you know this is not entirely avoidable.

Delivery

Now that we had a good app, it was time to get it in front of our users. This task was difficult and further complicated by the amount of content we were to add.

Just before the Summit

To ensure nothing fell between the cracks, I developed a comprehensive checklist that we had to tick off to consider ourselves ready for the Summit. The checklist covered the following key areas.

1. Legal and data compliance — everything we needed to do to ensure we properly handled the data we collected. We primarily used GDPR compliance to cover this. We also had to register with ODPC.
2. Security and backups — data encryption, secure-auth, API security, and setting up backups. We also did a penetration test at this juncture. An external entity audited the results of the penetration test.
3. App store requirements — covered all items we needed to have in place to upload the app to the different stores. This included items like the acquisition of the accounts (we started this at the beginning), app description & screenshots, and, importantly, the terms of use and privacy policy.
4. Functionality and performance included functional testing, bug fixes (based on our prioritization), design & implementation parity, performance, and load testing to ensure we could handle the traffic, redundancy/failover, and confirming that multilingual support was working as planned.
5. Product analytics — we set this up using Google Analytics. We didn’t have enough time to do it as well as I wanted, but we had the insights we needed
6. Marketing and promotion — material and brand collateral to share with the marketing team.
7. Content requirements — this was a tough one! We had content for the Africa Climate Summit, Africa Climate Week, and Africa Youth Climate Assembly. Each eveSummit its own set of speakers and events. We had a script to upload the content but still had to confirm each event before publishing. In addition, event details were changing as we worked on this. Were it not for a very hardworking and diligent person called Sandra Kwamboka, I don’t think we would have had all the content up on time.

It is important to point out that we also had a couple of major changes 3–4 days before the Summit. We could execute these changes, but it forced the team to work late at night. I remember a Thursday, Felix, the front-end lead, sent me an APK at 12 a.m. for testing!

During the Summit

Monday 4th September finally arrived, and we were quite jittery as the team. We had already seen a lot of downloads and sign-ups over the weekend because of the Youth Assembly, but we knew there would be a deluge of users on Monday. We had two primary concerns (security and load) and two other concerns (bugs and continued development).

• In the build-up to the event, we had seen a lot of attempted attacks, but we had weathered all of them. Monday would be a bigger test because of the publicity of the Summit.
• We conducted thorough load testing but were still cautious about this.
• The third concern was the chance that a critical bug(s) would appear in production. We conducted thorough testing before the launch, but seeing the timeline we had in place, this was still a concern.
• Last but not least, we were still improving the app as late as Tuesday. While not ideal, we strongly felt that there were improvements we still needed to do

To mitigate these challenges, we came up with the following plan.

1. The design and development team were on standby to fix any issues that might develop. A few minor issues came up, and we were able to make the required changes.
2. We had a team at KICC with a booth. This was our on-ground support team.
3. I acted as the primary support contact with all requests going through me. The changes were mainly content updates and sending out push notifications. Having one point of contact made sure there were no confusing requests and requests were triaged before implementation. As an example, I was careful not to spam our users with in-app notifications as this would reduce the effectiveness of the service. This feature was only available to me :-)

We didn’t have any major incidents during the Summit. We know some users had issues with the app, and our on-ground support team addressed these where they could. The summit days went well and spoke to the team’s effort.

In conclusion

The 6–7 weeks these projects took were some of the most intense weeks of my life. I am proud of what we achieved as a team. It was a privilege working on this, and I left with so many lessons. I would work again with each team member I had for this engagement!

Need help with a new concept, an ongoing project/product, or how to structure your team better? I am currently taking on paid consulting gigs, and the services include product strategy, design, and development. My expertise also extends to UX research, design facilitation, and helping teams structure to improve how they deliver. Reach out on LinkedIn or via email hello[@]kirui[.]co[.]ke.