Skip to main content

Visma InSchool’s UX team introduced the value loop in their process

Visma InSchool is an administrative system for Norwegian upper secondary schools. Its launch wasn’t as we hoped it would be and in this blog, we highlight what happened when our designers introduced the Visma UX value loop to the other teams.

Visma InSchool’s UX team introduced the value loop in their process

A bumpy start

Visma InSchool is a cloud based administrative system used in Norway to manage upper secondary schools. After piloting for a year, the product officially launched in August 2019 in 34 schools of county Viken (Akershus at that time) and the reception was less positive than we expected.

The production of the product had been driven mainly by the development of contractual requests and so the focus on UX got blurred. At the time, we only had one designer in the office – compared to several developers.

Needless to say, this did not allow for a proper UX process and our designer was mostly brought into projects that were nearly done and in need of some “UI fixes”.

A new hope

A new UX team was created one month after the launch in 2019 and a dedicated UX researcher based in Norway joined forces at the beginning of 2020.

Since day one, our new team worked with the focus of improving the UX process in the production workflow. We advocated UX and the Value Loop in meetings and on the office walls too, getting more and more recognition for this process.

Now, after one year, we can showcase two projects that are using the Loop and how this changed the approach and the results obtained.

The posters describe the UX myth that "People read on the web".

Timetable: school year planning

The idea behind InSchool’s timetabling system is great: enter your requirements – subject hours, room sizes, teacher preferences – press a button, and (like magic!) you have a working timetable for the entire school year. 

The only problem? It wasn’t what our users wanted.

The first part of the Visma UX value loop is about understanding the problem and exploring solutions. In late 2019 we travelled to Oslo to meet the people who had been using InSchool for the past six months. 

Over two days of workshops, we got to know them and how they worked. They showed us how they used our software and what we needed to do to make it better.

A user journey map of the timetabling process showing that the users start in an happy or neutral mood and quickly becomes irritated and frustrated.

One of the biggest issues for them was the way we display error messages. The messages were supposed to let them know when a teacher was scheduled to be in two places at once, or a room was double booked. 

Every user we talked to had thousands of errors in their timetables. This not only led to scheduling mistakes, it meant they couldn’t use the auto-scheduling functionality. Users with particularly high numbers of errors also saw performance issues.

We knew we needed to change the way we were displaying that information, so we created three prototypes:

  1. A dashboard allowing users to sort through and manage a large number of errors
  2. A smaller change focusing on making the messages easier to read
  3. A complete overhaul of translations, combining messages where possible and focusing on improving performance
A rough, black and white sketch of our first idea, a dashboard for errors. It would allow users to search and sort through a large amount of errors... but is that what they need?

This is where the value loop truly shined. The first option sounded great, but we knew from talking to users that they weren’t interested in the errors themselves: their goal was to have a working timetable. As we talked through the problem in our team, we realised that while the third option was going to be the most difficult, it was the only one that would fix their problem. 

Our product owner said: “[Working on this project] was a revelation to me. Users are not looking for bells and whistles. They just want to get their problem solved.”

In the new year, we’ll close out the final steps of the value loop. The development team is fixing data structures while we iterate on the visual design. Once released, we’ll collect feedback with a Wootric survey that we can compare to our baseline from last year.

Archive search: find documents among hundreds

This is the first project that we started with proper UX research.

What we call “The Archive” is a backend collection of correspondence documents and other data processed by the system at a school and county level. Each special education request process, each warning letter issued, each appeal process, and so on. Specific users have the task to search past documents in this archive and for this, we needed a dedicated tool.

At the beginning of this project we didn’t have a UX researcher, nor did we have support requests or other data to support the definition of the problem. This feature is a contractual need and the PO gave us as much information as she had. The first wireframes looked a bit generic and reductive.

A small wireframe made of just three steps.

Gladly, our UX researcher joined the team while this project was on hold and, with the permission of the PO, she restarted the project interviewing some users in positions to use the search tool.

Her work, summarised with tables and charts, provided clarity on the behavioural patterns that drive the archivists. In particular, we understood that our users would start in one of two ways: looking for a pupil, or looking for a document.

User mindset highlighted.

Although we could provide them with many filtering parameters, it was clear that those archivists don’t want to lose time setting up complex search queries. They’d rather proceed step by step, starting from an easy choice: student or document?

With this and more other knowledge that has been unlocked by the research, a new low-fidelity prototype was made and, once tested, resulted in a high System Usability Scale (SUS) score.

Note: the lockdown in Norway was forcing everyone at home and for limitations in Balsamiq’s permission levels, the prototype couldn’t be navigated by the users themselves. This could have affected the results but, we think, not as much to alter the overall positive outcome of the test.

System Usability Scale scored 84/100 (composed of: Net Promoter Score, acceptance, adjectives used, and grade).

Having a dedicated Norwegian-speaking researcher that could follow the process all the way through, made us more confident going forward and definitely helped to define better the scope of the design and also the copy in our UI.

We are based in Dublin and design in English, while the product is intended for Norwegian schools, so it’s not rare to get lost in translation.

The final design was much wider than first iteration without research, including two paths and several screens.

Although this project is still under development and we don’t have results to present yet, we do have plans for measuring user satisfaction through Wootric and support requests. Good results would also corroborate the strength of a complete UX process.

Conclusions

Introducing the Visma UX Value Loop has required time and lots of combined team effort. We promoted it with posters, at meetings, and our team lead advocated it with other team leads and product owners.

Little by little, we got recognition and trust for our work on different projects. Especially effective was to let developers and product owners hear the real users talking about their experiences with the product. 

We had to find our space and for this, the delivery of a feature is now planned weeks or months ahead, making the workflow longer but in the end, we hope, more reliable.

There still are no measurable results for this work, change takes time and patience, but stay tuned, updates will come!

Written by: The InSchool UX team by Anastasia Prince, Andrea Avesani

Want to read more about what it’s like to work with design and UX in Visma? Visit our Design category page.

Read more about Design & UX

Most popular