Sketch, code, repeat. How we prototype software projects

Ernest Walzel
lab.SNG
Published in
3 min readMay 7, 2021

We just launched Akcia ZET: a blog-like exhibition website featuring a “live” peek into the gallery space. There, Marcel Mališ is creating an authorial replica of the Thanksgiving of Czech and Slovak People to Generalissimo Stalin: a controversial yet iconic work of socialist realism that mysteriously disappeared.

From its inception to its delivery, this project naturally took some twists and turns. Today, we’ll describe how we helped shape an idea into a solution with the help of prototypes.

Left: Our new web features a time-lapse of a massive (8,7 × 8 m) painting in the making. (Photo by Juraj Starovecký); Right: A print reproduction of the original work.

Our projects usually start with a “business owner” (a curator or a project manager) coming to us with a request:

I would like a simple website like Medium for publishing articles, but I need to be able to upload videos, podcasts, show upcoming events and downloadable files.

The business owner usually has a pretty good idea of what kind of content they want to communicate to visitors but typically the content itself does not actually exist. Our job as a software team is to help them find a suitable technical solution for the idea and the content-to-be. So we turned to prototyping.

There are many ways to prototype a website, ranging from sketching with pen and paper to creating a clickable demo. Whatever the tools, prototypes should be quick and dirty: easy to make and change.

With prototypes, we’re trying to figure out things like navigation, page sections and features. We’re not figuring out visual aspects such as colour schemes or typography at this point. It’s all about the content and its organization.

One thing to not skimp on during this phase is copywriting. It’s good to avoid filler text such as lorem ipsum as much as possible. The prototype should have no visual frills, but it should communicate each element's function at first glance.

A good rule of thumb is: make your prototypes boring and extremely clear.

Here’s a clickable prototype we made in Figma.

Prototype wireframes. Don’t they look pretty? Nope, they don’t, and they shouldn’t!

You’ll notice our poor choice of typography and colours. It’s deliberate: by making the prototype look ugly, we can focus everyone’s attention on what matters right now — features and usability — and not visual details.

We borrowed a lot of ideas in the prototype from the excellent Rijksmuseum’s Operation Night Watch website. Using a well-made website as a template helped us get many design decisions right on the first attempt. For the rest, it didn’t take long to change the prototype into the desired form.

Despite its lack of visual finesse, a prototype usually generates a set of constraints for the visual design. It may come as a surprise, but designers often welcome these constraints, as they provide a good initial direction for their creative work.

Visual design proposals. Each page has its mobile and desktop version.

The designer on the project, Branislav Matis, created high-resolution designs using Adobe XD. The designs included each different page type (e.g. home page, list of articles, article page) in mobile and desktop variants.

As we integrated the visual design in our code, we would regularly share the product as a live website with the rest of the project team. This way we could gather and implement feedback early and frequently. As a nice bonus, most changes requested were minor or cosmetic— thanks, prototypes!

--

--

Ernest Walzel
lab.SNG
Writer for

Software engineer with a thing for UX and fonts. Formerly Amazon and bioinformatics. Now helping out at lab.SNG