From Disco to Material Design 🦄
Cooking up a Visual Identity within a Design Framework
In this post, I'll illustrate the process of creating the visual design for Skriba and explain a few key decisions regarding the look of the application. This is a follow-up to the post in which I described the process of redesigning the usability and content New from Old.
After specifying the first requirements and drawing the first wireframes, we were ready to tackle the visual design. We started off by doing some research on how other web tools handle configuration features. We also looked up the flashiest new graphic design trends for inspiration. I could sense that I was gravitating to darker themes with pastel colours - they seemed to match up on the mood board.
During the prototyping phase, we had defined that the users will always be able to see the draft, i.e. that they could always see a preview of the letter as it would look. A piece of paper is much more visible on a black table than on a white desk. It therefore just felt right to go with a dark background, because it would help distinguish the difference between work area and preview area.
First drafts in light and dark
Working with Material Design
Minimalist that I am, I started out rather optimistic and very flat; I based the design on Google's Material Design style guide and only showed elements that where absolutely necessary. Having drafted this rather quickly, I showed it to the frontend developer and he was rather sceptical - immediately seeing that I had in fact broken some rules of Google's framework. He then quickly built a prototype using Bootstrap and immediately ran into the first issues with the material radio buttons. He then decided to try it with Angular Material instead, which, in his own words "created a whole new set of problems". Even though he wasn't exactly convinced by Material Design in the beginning, he gradually became a bit of a "fan boy" (still his own words).
Together, we developed the design further and then showed the design to some colleagues. No one directly opposed it, but there were concerns if users would understand it. To make sure we don't base our decisions on assumptions, the developer quickly built a clickable prototype that couldn't do much but which covered the two main steps.
During the usability tests with this prototype it became clear that Google Material Design is already widely known, because none of the test persons had a problem with it. With some of them, you could almost sense that they had an android phone in their pocket. But even the test persons who weren't as familiar with Material Design showed little to no hesitation with this kind of forms. It became clear that Google has crafted a well working design framework that can be used with many user groups.
During the usability tests we also learned something else: While the test persons didn't have any issues with the fields, the menu bar or stepper bar wasn't immediately obvious to them. Even though it was in plain sight it wasn't standing out enough. To fix this, I created a version with the boxes around all of Icons and added descriptions to the icons. This helped, but now the design looked very heavy. So it turned out that going two steps forward proved the concept, but I then went one step back, because I found it too strong.
A little too little, a little too much and finally just right
Choosing a color scheme
Remember the black background websites with neon colours from the 90s? In these early days on the interwebs we saw a great number of rather savage looks. I do have to admit that I am into the more Brutalist movement stuff coming back now, but there is a time and place for such languages - this app not being one of them. This doesn't mean that we couldn't push for a modern look - just not avant garde. So while creating an app with a dark background, we had to be careful to avoid a faux pas and focus on a more soft look.
What do I mean by "soft look"? The background shouldn't be full black. Instead, it is anthracite; a muted dark grey background. As you can see in the example below, I experimented with a few different color palettes. On the left side you see the pastel ones and on the right hand side the more saturated colors. This illustrates beautifully how colors change in combination and how they influence each other greatly. Note how the anthracite background behind the color variants looks like a gradient, looking a lot lighter on the left than the right. Just an example how our eyes can deceive us.
Playing with these palettes in the navigation looked something like this
And here is what it looked like when we implemented the color scheme on the page
Disco right? While definitely fun, this color scheme wasn't saying what it should be saying at all. So that experiment with a palette died pretty quickly. "Killing you darling" was probably one of the first things I learned when I first started out. Before anyone had taught me anything of the design process I would obsess over drawings and paintings until I would ever show them to anyone. This was untaught very quickly in the first days of design school. Teachers would literally take away drawings from out under us. The amount of attachment you learn to form is not correlating anymore with the fear of someone ripping it to shreds (figuratively and literally). In the tech world people love to say "fail early - fail often". This has to be practiced, especially in cultures like Switzerland where we are believed to only be allowed to create perfect "Swiss Made" products. The thing is, making things “perfect” just doesn't hold up when making something people will have to be able to use and look at and incorporate into their workflow. Hence the importance of iteration. Nobody is born perfect and we can't expect things we faulty humans create to any other standard. But we do improve over a lifetime - and so should our products and creations.
Coming up with a name
As mentioned in the previous blog post, this application was a redesign of an existing app called Sommer Zeugnis Tool. We wanted to leave that name behind as we were taking this on. I believe the following process would probably horrify brand developers. Surely. But better done than perfect.
My process was probably pretty close to all my other processes: First what is it? Well it is a sentence generator in some sense or a click-through stepper for a solid block of text. If it were a human it would be a scriptor. That was one lead. Then there was the output, which was a certificate of some sort. There were many leads like that, but the one I got hung up on came through the danish word for "to write" - "at skrive", then researching and looking at the etmyology for that word and its descendents. So I played around with that for while talking to the team about it. Many came with variations. I narrowed them down to these two: Skriba and Certifa. We ended up choosing Skriba after doing a hallway test: We asked a dozen coworkers who weren't involved with the project how they felt and what they thought these products do while just presenting the name. Skriba clearly resonated in a more meaningful way than the more generic-sounding Certifa. You can imagine, generic-sounding is a big no-no when talking about a text generator.
Name finding wordplay
Finding the right kind of icon
I love how the process of the name reflects in the icon process. First we stayed with the "Z" of Zeugnis Tool and incorporated actual tools like a pen and a ruler - very apple 2011, I know. In the middle of the journey it was just a pen, which was nice and all, but also pretty abstract, and not usable as favicon, for example. So in the end we went with the "S" of Skriba in the signature Coral color.
Designing the logotype
The fun 80s version. This was probably my favorite thing I made in all but two minutes. I wasn't entirely serious about this, of course, but thought of it more as a joke to share with the developers. Laughs were had and the final logotype was right there as well.
Living the disco life
All it needed was some kerning and it was done:
Wrapping up this post
I do want to state how well the images shown represent the iteration that goes into the process. You can see very few things ever stayed the same throughout. Most adjustments go through the whole application, requiring changes constantly. Much like life, the process is rarely a straight-forward one, but one with obstacles, bends and surprises.
You can check out Skriba with all of its functions on the demo page
For more information, please visit the Skriba product page