Redesigning an existing software solution comes with an array of challenges: There is the code, which might have been written by people who don’t even work at the company anymore. Then there are these patterns, that the users have gotten accustomed to – no matter how complicated they may be. And then there is the visual design that might not be the most modern anymore.
So when redesigning an existing software, we essentially rework the substance and fabric it is made of. And that’s what makes these projects fun, challenging and rewarding.
From Sommer Zeugnistool to Skriba
But let’s start at the beginning: Sommer Zeugnistool is a tool for generating letters of recommendation, or “Arbeitszeugnisse” in German. On the Swiss job market, these letters play an important part in the job application process. The Sommer Zeugnistool supports HR employees and helps them writing structured and legally binding letters.
Edorex developed this tool for Heinz Sommer a few years ago. Last year, we decided to take it on as an inhouse product partnering with our previous client. Edorex specializes in developing tailor-made software for clients. Taking this on as an inhouse project meant that we could decide how to go forward with it. For us, it was clear that we wanted to reach a number of goals: We wanted to radically overhaul it. To improve it, we knew we had to focus on usability. Given that for each click 10.000 requests are being made in the background it also had to be fast. But in addition to that, we wanted it to look great. We wanted it to look snazzy and to show people what we got.
Step 1
Evaluating the existing tool
First of all, we evaluated the old tool. Maybe it wasn’t the prettiest belle at the ball but clients have been loyal – so we had a closer look at its values and functions.
We knew we had to understand and restructure the application before taking out the moodboards and stylesheets. It was important to get the skeleton right first: We had to really understand what this tool was doing and what makes it so valuable in an HR workflow. So we went to the source and talked to users. We wanted to find out what worked for them, what workarounds they had figured out, and what functions frustrated them.
Step 2
Identifiying the essence
After that we took apart the existing application apart, eliminated unnecessary steps and rarely used features. By doing that, we simplified the process and reduced the number of workflow steps from 11 to 4. The sentence generator became the center of the application.
To get to that result, we printed out all screens. We had to break away from the digital realm, and actually hold the screens it in our hands and play around with them. Letting this process happen organically and not just in your mind can be really helpful to not let small micro processes and workflows slip through your grasp.
Step 3
Identifying the user group
For this product, our target group was “HR personnel” – which isn’t the most concrete user group. Age and most other persona hooks didn’t really apply. The one thing they all had in common though, was that they all cared tremendously about their coworkers and are in tune with the emotional aspect of this document. We also knew that they would have a certain affinity to computers, so this gave us the freedom to push for a more minimalist user interface.
Step 4
Sketching the new solution
Now that we had identified the key components and the users, we were ready to go to the drawing board.
Every designer will start off differently, but we all know that the first step is the hardest. The blank canvas is daunting. But you have to start somewhere. Sometimes I like to start with a rough layout: Should the navigation be here, or there, or maybe it can be floating here? Just a rough idea; a small step into getting something on the canvas. Here are a few examples:
The next step was to take the four touch points mentioned above and fleshing them out. This has the benefit that now we can move away from a hypothetical scenario and start discussing something concrete.
Showing the shoe first is something people appreciate. There’s nothing worse than working in the dark. We wanted the user to be in control and see the changes take effect as soon as they clicked or toggled an element. With that in mind we knew the layout with the document would be using roughly 50% of the interface. That is a lot of real estate, but it is also well deserved, because it gives the user all the feedback to confidently go on in his task.
This view is the heart of the app, it is its core function. In the existing app, this view had a pretty complicated process and had so much function that you didn’t know what’s what. While redesigning the application, we had to be mindful of existing users: Even though this new view was completely unfamiliar to them, they still had to be able to get their work done efficiently.
The following images illustrate how a complicated process can be streamlined if one is harsh and cuts out all non-essential items:
Step 5
Visual design
After we had a rough idea of what the layout would be like, we transferred our findings and general ideas into sketch.
From the beginning, we involved users and tested our ideas with them. Trial and error helped us finding out what works and what doesn’t.
We went through a few design iterations and kept improving both the usability and the visual design. We learned a lot throughout this process and these are the dark and light looks we wended up with:
P.S. We will write more about Skriba’s visual identity in a follow-up post, promise.
Conclusion
We are very happy with the result so far – and more importantly, so are our users. You can check out Skriba with all of its functions on the demo page
For more information, please visit the Skriba product page
