Prototypo is a web application that makes it possible to create your own fonts in a few clicks. Instead of drawing each letter of the alphabet, you customize built-in typefaces using sliders. You can then export your font for use on your website or in desktop applications. You can also use a browser extension to preview your font on any website as you edit it.
Type design: The last frontier
The idea emerged from the frustration of a designer confronted with the last frontier of graphic design: type design. Typefaces are the cornerstone of any visual identity
, and yet most of the time, we reuse fonts that have already been used a thousand times—and they don’t fit our creation perfectly. That’s because creating a font used to take weeks or even months.
Prototypo, unlike other type design tools, is simple by essence: Instead of spending countless hours drawing every character you need, you start with one of the built-in templates, designed by our partner Production Type, and customize it to your needs.
“UX quality control is a constant process.”
After we released the first version of the tool, we gradually added features that allowed users to manage a personal library of font projects and further customize their fonts. Soon we realized that Prototypo was no longer as intuitive as it once was, and that new features were seldom used. We knew it was time to make Prototypo “as simple as it seems” again.
Apps can age, too
Having limited design resources, we decided to team up with Stash, a local agency of UX experts, to conduct a fairly standard usability audit of our app. Together, we recruited a dozen designers and made sure to have a good panel of new and returning users, working on the web or in print. After that, we set up a 45-minute scenario that designers would have to go through, as well as a list of questions to collect feedback on the overall experience.
After all the user testing sessions were carried out, Stash produced a summary of what went well and what tasks users struggled with. This was followed by a set of recommendations on the area that required improvement, as well as a few mockups illustrating these recommendations.
As expected, designers found it very intuitive to customize fonts using sliders, but some recurring problems surfaced during the tests:
- The visual cues used to differentiate the states of the interface (hovered, selected, disabled) were not all coherent
- The number and placement of menus in the application needed to be rationalized
- The individualization mode, which allows adjusting the value of sliders for a restricted group of characters, was too complex and hard to access in the UI
- The personal library had some issues that were making it frustrating to use
- The contextual menus available on right-click were ignored by all users. This is a UI pattern that is far from common on the web, so users never guess when one web app uses it. By the way, did you know Google Drive has context menus?
The app was far from being unusable, but the effect of time (and frequent updates) was obvious. We had to face it: The app had aged.
Plastic surgery to the rescue
So we decided to redesign the 2 most problematic features from the ground up in order to reverse the process:
- The personal library would look and behave more like the Finder in macOS
- And the individualization mode would become a more natural step in the design flow by surfacing them in a prominent breadcrumb menu at the top of the app
Redesigning the individualization mode was the longest part. The very first problem was that most users didn’t even notice that this feature existed. We imagined this mode as the last step of our parametric design process: You create a font family, then you create some variants, and finally you tweak some letters or groups of letters to refine and sharpen your design.
But there was no visual indication guiding users on this path. We fixed this by materializing the path using a breadcrumb menu.
The second issue was that users didn’t really know when individualization mode was on and which letters were affected. We switched the entire color theme of the UI to yellow and darkened characters subject to individualization.
The rest of the team validated the initial mockups, which we implemented in the following month. Once everything was in place, we began producing a tutorial video to guide new and existing users in the new Prototypo.
In parallel, we recruited a few beta testers to play around with it as part of our QA process, and we launched a PR campaign to announce the improvements that were about to be released.
“UX debt will build up in your app and needs to be adequately taken care of.”
Don’t outsource—find partners
In retrospect, we’re really glad we trusted this audit to someone outside of our team. Not only did we benefit from Stash’s expertise and learn from their experience, but our absence during the test sessions made users more comfortable sharing their honest feelings. The fact that they summarized feedback was also an additional guarantee of objectivity, as data doesn’t speak for itself and can often be interpreted with a bias. Key tasks such as a UX audit shouldn’t be delegated entirely. For those tasks, you should search for partners to work with and learn from, not simply outsource to.
User experience debt
UX quality control is a constant process. It’s not because you feel you’ve achieved a very pleasing UI and intuitive UX at one point in the lifecycle of your app, that this will stay true forever. It’s actually very easy to add features one by one, and slowly lose coherence and ease of use. Just like technical debt will inevitably build up in your code base and need to be refactored away, user experience debt will build up in your app and needs to be adequately taken care of.
Now that we’ve paid this debt and strengthened our UI and UX guidelines, we’re in a good position to continue to innovate. We’ll give the final stroke to the last frontier of design by allowing external designers to add their own font templates to Prototypo, and by integrating our smart parametric fonts into third-party software.
LRB's passion is to create websites and web apps. He fell in love with JS in 2004 and has contributed patches and features to jQuery 1.X (if you have browsed the web in the past 10 years, you've used some code he wrote). He's helped start a local JS meetup: lyonJS.
