ALAN Experimentation Portal MVP1 Prototype (2021)
Group Planning & Strategy, Transformation Group
Experience Strategy Team
When I was a trainee fresh out of university, I was tasked with 6 other people to come up with a wireframe flow of an in-house data library that records experiments done within DBS. The ask was to come up with a flow that was easy to use and less tedious, as the current database on Sharepoint had little automation and freedom for navigation. It also required people to take many steps to view and upload experiments on the portal, which discouraged many from doing so on a regular basis.
Hence, the product team wanted a tested and proven means of deciding what features to include in the new experimentation portal, ALAN (fun fact: named after Alan Turing).

Bird's Eye View of an easy-to-understand proposal for the product team
As an MVP1 Prototype, the ask of this project was purely on designing a good journey flow. After completing a first prototype, we took it upon ourselves to run A/B Testing with a few bank staff to understand the user experience from an actual user of the platform. This first version was solely based on a powerpoint brief the product team wanted to work with. Throughout the 1-1 30 minute sessions, we conducted moderated testing with the users and recorded down the quantitative and qualitative feedback based on their real-time reactions to our prototype. 7 sessions were conducted over a span of 2 weeks. We honestly would have loved to conduct more tests, but we could only conduct the testing within December and had a 1st Jan deadline.
After understanding the jobs to be done, needs and pain points of the users, we had a one week turnaround time to product a revised prototype. The revised prototype would address the most reasonable and applicable feedback from the first round of A/B Testing. We then spoke to another 8 people and conducted 1-1 30-minute A/B Testing again to ensure that we covered most gaps we could address.

After finalising the MVP1 Wireframe Flow, I proposed the new flow to the product team and gathered a lot of good feedback on the prototype. I also took the chance to address potential issues highlighted by both our design team and the actual users of the platform, where limitations were due to the nature of the portal as per demands by the product team (E.g. they wanted to remove features that were found to be useful, etc). The product team then went through multiple back-and-forths and made decisions based on the qual and quant data I extracted from the team's research, and the first launch took place in February once everyone was back in office.
Honestly, this was a hard project to work on as a beginner designer because even though the brief was tedious, it was actually pretty straightforward to dissect. There was no brief for design except for highlighting features to put in. I had a couple of fellow co-workers who took the brief as a design brief and decided to focus on the design aspects of the current interface (the original interface wasn't the prettiest) and neglected the actual wireframe flow, which I subsequently had to fix when they lost interest in the project.
As tedious as it sounded, it was still a great learning experience because this was my first wireframing project fresh out of university. It taught me how to work with people of different perspectives, taught me problem-solving, trained me on mediating between disagreeing colleagues, and made me more used to the overall structure of a corporate environment. I definitely developed more on my own after this project, and with the increase in my knowledge and skills, I definitely would have changed so many things I did on this project. Gahh.










