Case Studies

A new web app architecture: How to combine 3 solutions into 1?

webapplication architecture

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.

BSCS Science Learning (A science education nonprofit organization from the United States)
Creating a new information architecture
Cooperation period
January 2020
Number of sprints
Number of people in the project

Project context of creating a new web app architecture

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.

Get our 30+ Lean Canvas and Templates!

Sign up now:

    I agree to the processing of my personal data by Project: People Sp. z o.o. for the purpose of marketing communication in accordance with Privacy Policy

    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.

    webapplication architecture

    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.

    webapplication architecture

    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.

    User Personas

    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 app architecture – let’s join the conclusions together

    Knowledge organization

    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 app 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.

    webapplication architecture

    Validation workshops

    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 app 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.

    webapplication architecture

    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 app 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
    • Personas
    • 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?

    Let's talk

    Project team, i.e. who was responsible for what

    Author of the Case Study

    Agnieszka Zygmunt Lean UX Researcher, Industrial Design & Service Designer
    Agnieszka performs analyzes, conducts research, and experiments. She specializes in Product Discovery research and helps create solutions focused on the real user needs.

    She takes a holistic view of the design process accounting for t all factors that may affect the final user experience. In her work, she combines her analytical skills with a high level of empathy and love of science.

    Co-creator of the Proste Rozmowy podcast. Privately involved in non-profit projects supporting those who need it most.

    Other members of the team

    Tomasz Osowski Lean UX & Service Designer w Project: People
    He helps companies create an excellent user experience while ensuring the profitability of their business. His job is to create products and services that are in demand and satisfy both the consumers and business owners.

    Certified Business Coach, Personal Development Coach, and Certified Design Thinking Moderator. Tomasz is also an entrepreneur sincerely in love with Lean methodology. He always works to get a product to market as quickly as possible with the least capital outlay.

    He has cooperated with companies such as T-mobile, Ecard, inPost, ING, Nationale Nederlanden, Brainly, Publicis, Netguru. Organizer of DesignWays Conference.