Facilitate the exchange of documents and assignments
4M+
users concerned
As a SaaS provider for schools, Edifice develops collaborative apps for teachers, students, parents, school staff, from primary to high schools.
3
main design iterations
Between Q4 2023 and Q1 2024, I dealt with this iterative and discovery project. This allowed the Product team to reframe and expand its strategy.
4
user profiles interacting
The initial goal was to simplify teacher-student assignment exchanges, but now it includes all docs exchanges between all user profiles.
4M+
users concerned
As a SaaS provider for schools, Edifice develops collaborative apps for teachers, students, parents, school staff.
1
regional client acquired
As a Product Designer at Edifice, in Q1 2024, I redesigned the app Wiki. The solution helped to acquire a new regional client.
7+
main features redesigned
As a Learning management system, Wiki enables mostly to create, edit, shate, move, duplicate, delete, restore pages and sub-pages.
2
targeted subscriptions /user/month
As a young organizer of events, La Maison Perchée gathers people and aims to convert users into active members.
40%
targeted event registration rate
Regularly, the registration rate was not optimised, and the subscription experience needs to be improved.
3
months to launch the portal
User tests, interviews, and prototyping activities integrated into development sprints enabled to build quickly the solution.
Challenges & Mission
1
Unclear problems statements
The team was uncertain about the pain points and their causes. I had to clarify them through user research.
2
Unclear goals
The team lacks of an action plan. I had to frame the project, define a roadmap with stakeholder buy-in, and lead the team.
3
Short time to launch the solution
I had to lead the design activities (user tests, interviews, prototyping) in a lean and flexible manner to maintain the development pace.
1
Lack of knowledge about users
The Product team lacked knowledge of user practices: what documents are exchanged, between whom, and how? ➜ I had to gather user insights and identify the most critical pain point to address in priority.
2
Change of scope and direction
The scope and product vision were unclear: should we merge, redesign, delete apps, or create a central app and rethink the homepage? ➜ I had to help the Product Manager and team choose a direction.
3
Too many apps unoptimised
Many user complaints about getting lost in the platform, with at least 5 apps for managing assignments & docs, none being truly efficient.
➜ Ultimately, I had to design a solution to simplify assignment exchanges.
1
Usability issues
The app was not at all intuitive. This project was part of my recruitment process: audit the app and improve its usability.
2
Lack of features and vision
The app did not allow the main uses that teachers needed. I went beyond the exercise by identifying and designing truly useful features for teachers.
3
Lack of consistency
UX & UI were not the same through the platform. Once hired, I had to integrate consistently the new features into the app and the platform.
Iteration #1 - Lean UX to create quickly a solution
Upon arriving at the company, the Product Manager tasked me with prototyping a solution within 3 weeks.
Empathise
1audit of apps & usage data
25tickets & feedbacks from User support
5ambassador-users (teachers) questioned
2high school students interviewed
Define & Ideate
1workshop
1vision-project connection
1bencmark
Prototype
4main user flows defined
+20wireframes hifi mocked
1. First 'Empathise' activities verified uses and pain points assumed
Teacher goals (for middle & high school)
Create & Distribute assignment
Track collection 🔴 Pain point
Correct & Note
Send grades and/or corrected papers & anser key
Student goals
Consult instructions & material
Make the assignment with or without the platform
Submit / delete the assignment to replace it. 🔴 Instructions for submitting vary by teacher.
Consult grade & correction
🧐 Other discovery: In primary schools, teachers are not allowed to give written homework, so usage differs from middle and high schools. ➜ A challenge for the platform, which uses the same apps for all levels.
Audit & data
Apps assumed
🟢 Strenghts
🔴 Weakness
Rack
Users can submit spontaneously any docs. Quite a lot of users & simple to use.
Lacks essential features such as file organisation and batch downloads.
Exercice
Covers many features: create, share interactive tests or exam topic templates, scheduling, tracking, and centralisation.
Not a lot of users, it lacks visibility and is complex due to many features.
Mailbox
Many users & simple to use.
Any centralisation nor tracking of documents.
Homework notebook
The main tool for giving homework in a classroom.
Any collection of documents.
Files Space
Many users & it is intuitive to manage any docs there.
Students can see assignments that others have shared with the teacher.
2. Solution ideation workshop & choice of a direction
The workshop yielded diverse proposalssuch as renaming and overhauling the Exercise app, or reworking the Files Space, it implies: ➜ No strategy emerges as the best, ➜ Significant changes to existing apps would be complex and resource-intensive, ➜ Instead of the overhauls, the Product Manager and I suggested on a more feasible, flexible,and scalable approach: integrating a cross-cutting feature across multiple apps, through modals (excerpt below).
I benchmarked competitors and Drive softwares, to inspire the design of this feature. However, the Product team did not fully embrace this proposal because they had not been involved enough in defining the vision for this strategic project. This led to further iterations where Product Discovery truly began as a collaborative team effort.😊
Next iterations - Project reframed as a Discovery and team initiative
Due to the project's strategic impact, the product director extended the timeline to 6 weeks for further iterations
Empathise
2surveys & data analysis
5teachers interviewed
Define & Ideate
4product team workshops
1competitors benchmark
Prototype & Test
2solutions prototyped
4user tests
1. Surveys & data to identify trends and Interviews for a deep understanding
At this point, the Product Team aimed to identify trends about document types, applications used, use cases, and common issues among users.
Key findings: ◯ No dominant app for assignment management: practices vary significantly from teacher to teacher. ◯ No dominant types of materials: images, audio, written documents are exchanged. ◯ Common issue confirmed: not easy for students to submit homeworks. ◯ Primary school staff use Rackfor administrative documents (e.g., parental permissions).
Some questions remained: how do teachers assign homework? How instructions are provided? What actions do they take?... To understand how they do in the classroom and the platform, I led some interviews with teachers from 2nd degree, and documented the key findings into 5 personas and 5 experience maps (excerpts below).
Key findings: ◯ New needs discovered: Teachers need to communicate before and after deadlines, control cheating, send frequent reminders, besides performing batch actions (e.g., downloading, printing). ◯ Students use their phones over computers (e.g., recording audio for language classes, checking instructions). We decided to prioritise a 'mobile-first' approach for the student experience. ◯ Some teachers prefer to correct assignments in the classroom, while others do so both digitally and in person final stage depriorised..
SEE the BENCHMARK EXCERPT
2. Workshops to diverge...
The product team could not rely on uses to define a direction, as they were divergent. So, we organised workshops to study the pros and cons of different directions.
... and to converge on a direction
Ultimately, we agreed with the 'First Use Case' and voted on a main direction with two alternatives: ◯ Redesign Rack to capitalise on its many users ◯ Deplace and improve features from Exercice (collections, tracking...) ◯ Add a 'Comment' features to cover the conversation needs ◯ Delete "Spontaneous deposits' feature to focus only on assignments beetween teachers and students OR keep it to enable all documents exchanges among all user profiles.
3. Prototype the alternatives....
I created a moodboard of competitors to gather inspiration. Then, I converted user needs into a list of features prioritised, approved by the Product Manager. To address usability issues, I redefined the user flows using the 'Job to be Done' method. Finally, I tested different screen layouts and navigation through wireframes and mockups (excerpts below).
For example, to simplify navigation for the 'Consult and Submit Assignment' feature for students, I initially tried an 'expand/collapse' layout but ultimately favored a 'tab navigation' with fewer tabs for better responsiveness.
... and user tests on prototypes
I had a short deadline to recruit users and conduct tests. I focused the scenario tests to verify our main hypotheses and concerns: Are the primary user problems addressed? Is the student effectively guided through submitting assignments? Is it easy for teachers to collect and centralise students' assignments? Does the 'Collecting' feature integrate well with 'Spontaneous submission'?
The main user flows were successfully realised by testers, even by those unfamiliar with the platform. This reassured the Product team, enabling them to choose the alternative that allows document exchange among all user profiles.
Lean UX to launch quickly a user friendly portal
Empathise & Define
6usability tests and interviews
1atomic user research analysis
4roadmaps & business processes defined
Prototype & Test
20+responsive mockups
5user tests on prototypes
2adjustment iterations
Launch & Product management
10+user stories wrote & designed
12+agile meetings
I detailed my design process and results in the video below (please, put subtitles for non-French speakers).
1. First 'Empathise' activities verified some uses, user goals, and pain points that we assumed
🧐 Other discovery: In primary schools, teachers are not allowed to give written homework, so usage differs from middle and high schools. ➜ A challenge for the platform, which uses the same apps for all levels.
2. After a solution ideation workshop, a direction is approved by the Product Manager
The workshop yielded diverse proposalssuch as renaming and overhauling the Exercise app, or reworking the Files Space and removing Rack. This diversity indicates that there wasn't a single consensus on the best way forward. These solutions involved significant changes to existing apps, would be complex and resource-intensive. Instead of choosing one of the overhauls, the Product Manager and I suggested on a more feasible, flexible,and scalable approach: integrating a cross-cutting feature across multiple apps, supported by a dedicated space.
BENCHMARK & wireframe
After an inconclusive benchmark of competitors, I focused on Drive softwares and their 'Request a document' feature to inspire the design of our feature and its user flow.
WIREFRAME IN PROGRESS
The Product Manager and I presented this first proposal to the product team, but they did not embrace it because the Product Manager hadn't enough involved them in defining the vision of this strategic project. This led to other iterations where Product Discovery truly began as a team effort 😃.
II. Next iterations: project reframed as a Discovery and team project
My process - other iterations
1. Survey & data to identify trends and Interviews for a deep understanding
At this point, the Product Team aimed to identify trends about document types, applications used, use cases, and common issues among users.
Key findings
◯ No dominant app for assignment management: practices vary significantly from teacher to teacher. ◯ No dominant types of materials: images, audio, written documents are exchanged. ◯ Comon issue confirmed: not easy for students to submit homeworks. ◯ Primary school staff use Rackfor administrative documents (e.g., parental permissions).
Excerpt of the survey
Some questions remained: how do teachers assign homework? How instructions are provided? What actions do they take?... To understand how they do in the classroom and the platform, I led some interviews with teachers from 2nd degree, and documented the key findings into personas and experience maps.
Key findings
◯ New needs discovered: Teachers need to communicate before and after deadlines, control cheating, send frequent reminders, besides performing batch actions (e.g., downloading, printing). ◯ Students use their phones over computers (e.g., recording audio for language classes, checking instructions). We decided to prioritise a 'mobile-first' approach for the student experience.
◯ Some teachers prefer to correct assignments in the classroom, while others do so both digitally and in person final stage depriorised.
SEE BENCHMARK EXCERPT
2. Workshops to diverge and converge on a direction
The product team could not rely on uses to define a direction, as the uses were divergent. So, with the Product Manager, we organised workshops to agree on the 'First Use Case' (the problem) and to study the pros and cons of different directions, and we voted on a main direction with two alternatives:
3. Prototype & User test to compare alternatives
To prototype the alternatives, I created a moodboard of competitors to gather inspiration. Then, I converted user needs into a list of features prioritised, approved by the Product Manager. To address usability issues, I redefined the user flows using the 'Job to be Done' method. Finally, I tested different screen layouts and navigation through wireframes and mockups.
Example: Low-fidelity wireframe for teacher assignment receipt follow-up
For example, to simplify navigation for the 'Consult and Submit Assignment' feature for students, I initially tried an 'expand/collapse' layout but ultimately favored a 'tab navigation' with fewer tabs for better responsiveness.
Example of a high fidelity wireframe - rejected layout
Example of a mockup - chosen layout
About the user tests, I had a short deadline to recruit users and conduct tests. I focused the scenario tests to verify our main hypotheses and concerns: Are the primary user problems addressed? Is the student effectively guided through submitting assignments? Is it easy for teachers to collect and centralise students' assignments? Does the 'Collecting' feature integrate well with 'Spontaneous submission'?
Prototype extract with test scenarios highlighted in pink
The main user flows were successfully realised by testers, even by those unfamiliar with the platform. This reassured the Product team, enabling them to choose the alternative that allows document exchange among all user profiles.
2. Workshops to diverge and converge on a direction
The product team could not rely on uses to define a direction, as the uses were divergent. So, with the Product Manager, we organised workshops to agree on the 'First Use Case' (the problem) and to study the pros and cons of different directions, and we voted on a main direction with two alternatives:
3. Prototype & User test to compare alternatives
To prototype the alternatives, I created a moodboard of competitors to gather inspiration. Then, I converted user needs into a list of features prioritised, approved by the Product Manager. To address usability issues, I redefined the user flows using the 'Job to be Done' method. Finally, I tested different screen layouts and navigation through wireframes and mockups.
Example: Low-fidelity wireframe for teacher assignment receipt follow-up
For example, to simplify navigation for the 'Consult and Submit Assignment' feature for students, I initially tried an 'expand/collapse' layout but ultimately favored a 'tab navigation' with fewer tabs for better responsiveness.
Example of a high fidelity wireframe - rejected layout
Example of a mockup - chosen layout
About the user tests, I had a short deadline to recruit users and conduct tests. I focused the scenario tests to verify our main hypotheses and concerns: Are the primary user problems addressed? Is the student effectively guided through submitting assignments? Is it easy for teachers to collect and centralise students' assignments? Does the 'Collecting' feature integrate well with 'Spontaneous submission'?
Prototype extract with test scenarios highlighted in pink
The main user flows were successfully realised by testers, even by those unfamiliar with the platform. This reassured the Product team, enabling them to choose the alternative that allows document exchange among all user profiles.
No items found.
Results
A solution meeting user's needs
A centralised experience for teachers
A 'mobile first' and 'multimedia' experience for students
To conclude, thanks to the Product discovery, the initial opportunity evolved to handle all types of document exchanges, spontaneous or organised into collections, among all user profiles. I succeeded in dealing with complex challenges: ◯ Maintaining simplicity as much as possible in a solution that is now multi-functional and flexible, ◯ Enhancing team alignment and validation, ◯ Presenting multiple solutions, enabling informed recommendations to the Product team, ◯ Gaining deeper insights into the teaching profession, improving comprehension of user needs in EdTech, ◯ Considering responsive design early to ensure optimal solutions for responsive web apps.
