How to combine 3 solutions into 1 – New web application architecture within 2 weeks
Creating an intuitive platform for creating and conducting tests. How to combine the functions currently on 3 different platforms into one solution? About how we helped our client create a tailor-made solution, you’ll find out from the following case study about creating a web application architecture for a client from the education industry.
In December 2019, BSCS Science Learning – an American organization seeking to improve the teaching method – turned to us. The research conducted by the company is based, among others, on carrying out multiple-choice tests on a large sample of students, and the questions used are prepared by a special team of researchers ensuring the highest quality of information provided.
An unusual project – operating on an NGO basis, with a plan for a non-commercial product for internal use. Currently operating on 3 different platforms and unable to find the right tool providing all of the functions they need, they decided to create their own internal application.
We divided the process of work on creating the web application architecture into 2 sprints (2 weeks), and we involved two people in the project. The information we developed was to be an introduction to further, joint work on the website – creating UX and UI mockups for the application.
Sprint 1 – We learn about the product and the users needs
Learning about real usage needs
We started our work by getting to know the client himself – using two tools during our first introductory conversation: Team Canvas and Lean Canvas. Due to the limited form of contact (video-conversation), we have modified the traditional form of workshops for in-depth interview. Questions contained in Team Canvas allowed us to discover both the needs behind the desire to introduce changes to the project, the client’s personal goals, as well as the form of mutual cooperation (which, in the case of this project, turned out to be crucial). Lean Canvas has given us invaluable knowledge about the project itself – allowed us to get to know the organization from the inside, its mode of operation and other project stakeholders. Especially when it comes to a company operating in a different cultural zone, learning their approach and work method makes it easier to build a holistic view of the entire project.
Due to the fact that the customer is also one of the main recipients of the product (researcher), we were able to jointly go through the process of creating materials in the application, learning the client’s perspective and his methodology of work. Despite over 8,000 kilometers of distance, direct observation of his action on a shared screen has enabled us to establish a user path, as well as to learn about all the functions and problems of the current solution.
User Stories and their verification
After introductory familiarization, we started further analysis work by learning the tool ourselves. Thanks to access to each of the platforms, we were able to review each subpage thoroughly, outlining user stories for the personas distinguished by the client. The pre-outlined User Stories (a brief description of actions that the user wants to be able to perform), shared with us by the Bejamas development team cooperating with us, combined with self-discovery of the solution and observation of researchers, allowed us to outline a comprehensive list of functionalities for each of the existing platforms. While it was necessary for us to write down all possible actions when discovering the project, we knew that we weren’t able to transfer them completely to the new solution. In this situation, the MoSCoW method was used as a validation tool.
The MoSCoW method is a prioritization technique used to determine the value of providing each of the analyzed elements. There are 4 categories, according to the capital letters in the name of each: Must (M), Should (S), Could (C), Won’t (W). The most important for each project are two of them: the first and the last one. Must means categories that must necessarily be included in the project in order for it to meet its basic functions and user expectations. Won’t are actions that shouldn’t be included in the solution, since they don’t bring any positive value to the user or may even distract him. By simply marking each case in the User stories described, as well as by validating our choices with the client, we were able to quickly eliminate a large part of unnecessary options and highlight elements crucial for the smooth functioning of the entire research process.
The user stories we discovered were based on 3 main personas (overlapping with the existing 3 platforms) – a researcher, a teacher and a student. However, delving into the product, we’ve finally managed to develop 5 personas – an additional teacher and public user personas.
With such a large number of diverse users, it was necessary to separate access levels: public, for users with a general account, students and researchers. The increase in the number of people was caused by our noticing different goals and behaviors of people who until now were considered to be one persona.
Sprint 2 – Web application architecture – let’s join the conclusions together
When finishing the first sprint, we already had a detailed report, personas, hours of talks with the client and huge amounts of notes. The question arose – how to combine such a huge amount of information into one intuitive platform without missing the smallest detail valuable to the recipient? So we started classically – from the whole.
We have again gathered the previously collected and prepared materials in tables, where we grouped individual user stories using colors. We divided them into 4 main groups that were to be the core for further developing the web application architecture. The next step was to refine the access according to the persona. Tracking individual user paths, we asked ourselves a lot of questions – what access to the same preview of the question will have public figures, and what researchers? Should students also have access to a public platform? How will new projects be added?Our thinking was not only responsible for organizing the collected information into readable architecture. It was necessary to start thinking about project solutions to make sure that the architecture is not only legible, but functional in every aspect as well.
Having already a full set of information, we started working as true workshop enthusiasts – at validation workshops – working with sticky notes. Acting this way not only stimulates creative thinking much better than working on a computer, but also allows you to quickly introduce changes and new paths in architecture – tracking the path of a specific user, we could easily check whether the proposed web application architecture is clear and intuitive.
The sticky notes were color-divided according to the access of users – each subsequent color had a greater range of access than the previous one. This allowed us to apply one sticky note to a specific section, even if it was used by 2 people at different access levels. In the case of architecture, where there were so many accesses to one element with various restrictions, it facilitated the clear visualization of the whole architecture without unnecessary duplication of subpages.
Our client received the architecture we developed in a digitized version the same day, along with a legend and a brief summary. Based on the general outline of web application architecture, we have also prepared a detailed study for each of the subpages in the form of an excel file, where we have placed all the necessary information about the information, functionalities, access levels and possible guidelines.
Summary of our work – in numbers and more
Positions in excel
Pages of raport
Tools used in the project
- Team Canvas
- Lean Canvas
- MOSCoW method
Case study isn't enough?
Would you like to learn about the whole process and how we could carry it out in your organization?