Nancy Boshuijs
UX Designer & Reseacher


Why don't teachers like the native note-taking application?
Why don't teachers like the native note-taking application?



Teachers didn't like the Kijk! App for note-taking.


I researched why they didn't like the app and learned that the teachers thought that the note-taking process in the app took too long, that it was not time-efficient when observing groups, and that categorizing notes afterward resulted in double work.


To streamline the note-taking process, I added a group note feature, a learning line selector, and combined four screens into one.

Lessons learned

💡 A User Interface should be self-explanatory.

💡There is always something that could be better.

Why don't teachers like the native note-taking application?

About Kijk!

Kijk! is a web-based observational system designed to help kindergarten teachers track student's development by doing daily observations and taking notes.

The Kijk! app allows teachers to take digital notes and save them directly in the system, instead of having to write them by hand first and then retype them into the web application later.

Sounds great, right!? Then why don't teachers like the native note-taking app?

The app had a 2 star rating on average

The app had a 2 star rating on average


That was what I wanted to find out, so I started by analyzing user data that was already available: user reviews.

Although Kijk! has more than 34.500 users, mostly primary school teachers and child care workers, the app doesn't seem to be as popular. Users who left behind a rating in the App store tell us why: 

Recurring issues mentioned in the reviews:

  • '' No option to make registrations, only note-taking.'' 

  • '' Notes are not saved in the right place.''

  • '' Note-taking takes too many steps.''

When reading these reviews, I got the gut feeling that the app made the problem it was trying to solve worse: writing notes with pen and paper seemed simpler than using the app.

Before trying to resolve these issues, I wanted to know a bit more about the users' interactions with the app and validate the presumed problem.

Task Flow

To see what the users meant by ''note-taking takes too many steps'', I opened up the app and tried to make a note myself.

I noticed that this process consisted of 4 separate steps, spread out over four different screens, which indeed seemed like a lot for just making one note.

I also found out that once I clicked the save button, a 1 appeared on the note counter next to the child's name. Here I could only see the first few words of the note. There also wasn't an option to view, edit, or delete it.

Flow for taking a note in the app

Flow for taking a note in the app

Answers from survey participants

Answers from survey participants


Secondly, I was curious if other Kijk! users experienced the same issues as mentioned in the reviews, so I created an online survey and posted it on a kindergarten teacher's Facebook group.

In this survey, I included open-ended questions to get qualitative answers about:

  • what exactly the user did or did not like about Kijk!

  • how they took notes during observation and why

  • what their overall opinion about the app was

  • what they thought about the steps that they had to take before making a note (note->group->name-> note).

I also added some closed-ended and multiple-choice questions, in which I asked if the user:

  • had downloaded the app on one of their devices

  • when they used the Kijk! App

  • what they used to take notes: pen and paper, the application, a digital notebook, or anything else.

Lastly, I asked the participants what they would change to the product if they could change one thing. By asking this, I hoped to discover any other problems that the participant had not mentioned before.

Contextual Inquiry

By analyzing the survey results, I discovered that only 10% of users took notes digitally in the native or web-based application.

To find out why the other 90% preferred writing notes by hand, I scheduled 4x 2 hours with four different primary school teachers to observe them while note-taking in their classrooms.

During the visit, I observed their behavior and questioned their motivations for it while taking detailed notes.

Some questions I asked for better understanding while observing:

  • How many children do you observe per session?

  • What are you writing down while note-taking?

  • Why do you divide the children into different sections?

  • What do the X, /, +, - and flourish of approval stand for?

I had also asked them why they still chose to write the notes by hand, even it frustrated them to retype them in the computer later: 'I rather am frustrated once by retyping, than twice by typing and then categorizing.'

Why don't teachers like the native note-taking application?

Empathy map

I collected all insights into an empathy map to analyze what the teacher's main pain points were when using the app:

''If I have to do the work twice anyway, I'd rather take the easy step and write them by hand.''

  • The taken notes have to be categorized afterward, resulting in the same amount of work as writing it by hand and then retyping them in the system.

''Switching between children takes a lot of time.''

  • Most observations include a small group of children.

''It takes too much of my focus away during circle time!''

  • Teachers find writing a note down on paper faster and easier since typing and saving individual notes takes longer. Also, when they take notes digitally, their attention is more focused on the device instead of the children.

Problem statement

The pain points I discovered during research validated my pre-research hypothesis: 'Users found it easier to take notes with pen and paper than to use the app.' 

Through research, I learned that it wasn't the inability to save notes or make registrations that annoyed users which made them not use the app, but that:

  1. The four screens made the note-taking process feel too long.

  2. They had to do double the work by categorizing the notes at a later moment.

  3. Writing notes for individual students during a group observation isn't convenient because it takes too much time.

I then used How Might We questions to reframe the gained insights into a problem statement:

  • HMW streamlines the note-taking process for teachers?

After this, I went on to the ideate phase to explore and experimented with different design solutions.

Why don't teachers like the native note-taking application?
Why don't teachers like the native note-taking application?

Mid-fidelity Prototype

I created a mid-fidelity prototype based on the ideas explored during sketching. I included real-world input to assure that users testing out the design solutions would still recognize the purpose of the screens.

In this prototype, I included the following solutions:

  1. An option for the teacher to choose between individual or group note-taking, based on the observations they are doing. 

  2. One screen for all four note-taking options to make the process seem shorter. 

  3. Placeholder text to tell the user what should be written where.

  4. A dropdown button to select a development line so that the note would save into the right category immediately. 

  5. hashtag(#) tag line in group notes to write an observational goal in so that teachers wouldn't have to type it over and over again.

  6. An input field to tag(@) a child before writing a note.

  7. Clickable in-line name suggestions while typing to make child selection faster. 

Why don't teachers like the native note-taking application?

Usability Testing

I did six moderated testing sessions to validate if the designed solutions solved the problems and test if the affordance of the selected design patterns was good enough for all users.

During testing, I obtained the following insights:

None of the users understood the tagging pattern, and they all questioned what the # and @ were for.

💭 Most were confused about where they needed to type, as the affordance for the input fields weren't clear.

✔️2 out of 3 users used the name suggestions instead of typing the given name.

💡 The experienced users mentioned how much they liked the development line drop-down button and the observational goal input field: ''Now that I can select it here, it will save me so much time doing it afterward.''



Based on the insights gained during user testing, I decided to edit the prototype and make some changes:

Individual note:

  1. I changed the copy on the drop-down and save button by adding a verb it, creating a more compelling call-to-action button.

  2. I stepped away from the tagging pattern and replaced them with input fields for the student's name, the observation goal, and the note.

  3. I also added placeholder text for better affordance.

Group note :

  1. To make the 'goal' field stand out more than the name/note input field, I gave it a more noticeable pink stroke.

  2. I changed the scrolling interaction so that the development selector and goal input field would always stay visible, making another content scroll underneath. 

  3. Lastly, I took out the child tagging pattern and replaced it with a plus button.



💡 A User Interface should be self-explanatory.

Having seen the test testing participants struggle with the tagging pattern and questioning what the # and @ were for showed me that not all taught-up solutions are as logical to others as they seem to you. You'll never know if your problem-solving design works unless you validate it with users. 

💡 There is always something that could be better.

At the beginning of this project, I thought it was clear that the app wasn't solving the user's problems. But I experienced what the employees of Basalt must also have felt: I was sure that the app was perfect, but during usability testing learned that while the designed solution worked, users still ran into other problems with different parts of the app. From this, I learned that there will always be space for approval, but that you have to prioritize and tackle the problems step by step.