Designing a digital product can be summed up in a very simple idea: create an intelligent, logical, and practical itinerary through which the users can achieve their needs without getting lost.
At Z1, we craft digital products from scratch. They are great ideas, usually in an early stage, that we have to shape. Before starting to design, it is vital to know the project in detail and put on the table exactly what we want to do and what we can actually do. To make this task easier for us, years ago, I planned an infallible blueprint for designing an application: a working system based on blockframes, which are the minimum design units.
I took many things from my university years studying Architecture: The less is more ideology of a classic like Mies Van der Rohe, or the work with space, void, and limits of studios like the Portuguese Aires Mateus. Many of those lessons persist in my day to day and, especially in the idea of creating blockframes, which are a schematic simplification of our work, the abstraction of the screens of a whole digital product that we work on right after approving the list of features and just before working on the wireframes.
Blockframes are one more step in information architecture, but not just one more step, they are the maximum abstraction of a wireframe, in which we forget about the layout and the components to think only about the content, navigation, and main actions. Some may think that adding one more step to the design process can be cumbersome and that wireframes work well enough to establish the basic structure of a page before adding content and visual design. But years of experience have proved us right.
Creating blockframes boxes with the itinerary helps us to:
When designing a filter screen, for example, we can proceed in a thousand different ways. Taking into account both our experience designing this type of screen and all the already designed references, it is very easy to deviate and lose focus on what is really important. That’s why working with blockframes beforehand is essential to solve the screen we have in hand by incorporating only the necessary functionalities. It is our way of validating that we are doing only what needs to be done.
“Blockframes help us establish navigation, reduce uncertainty, and plan models that, in the future, can be scaled.”
We discovered the blockframes utility by working on an app to get people in contact with yoga instructors, physiotherapists, and other professionals related to physical and mental health. We had to define two profile users: clients and instructors. We knew what features would have both profiles, but we needed to connect them to make sense of all the flows and interactions.
We had a complex problem that only some kind of map or flow chart could help us solve, but tools like Miro felt short and inadequate. That’s why I opened a Figma file where I started to get features into simple boxes and established a color system to differentiate the content for each profile, the primary and secondary actions, etc.
Then I grouped them into containers and connected them. I had, at that point, the content and the actions that each screen would have and the flows that connected all the screens. In this process, I also identified loose ends and realized that we needed more details to define some content.
“If there are loose ends, we’ll catch them from a bird’s eye view before we’ve involved more people in the process and lost days of work.”
I saw that it had potential: Something as simple as organizing the features before starting to design wireframes allowed us to avoid putting the cart before the horse. I showed it to the team, and they agreed: It was the beginning of a new phase in the Z1 design process. We turned the blockframes into a common language in the studio, an organized system in which the colors of the boxes allow us to know if we are talking about content, action, secondary action, etc.
With this system, we never lose the thread of the main navigation of each of the sections. If there is a mistake, a path that could be improved, loose ends, or blind alleys, like in a maze, we will detect them from a bird’s eye view and correct them before involving more people and design effort in the process and having lost any workdays.
At Z1, we pride ourselves on having a process validated by more than a hundred applications. However, working with clients always entails an educational challenge that requires us to explain why the steps of our route are needed. Some find it difficult to understand the abstraction that blockframes represent, but we have verified that skipping the step of preparing the blockframes leads to blind alleys sooner or later.
For this reason, we are working on ways to make clients understand blockframes better, accompanying their delivery with presentations in which everything is clear and detailed for both parties. In fact, our team usually comes out of these meetings with insightful, valuable information for the rest of the design process.
This doesn’t mean we can’t go off-route if the client demands it. Flexibility is also one of our main tools, and we are adaptable, but we always explain to clients that if our trip has a series of stops, it is because it has been proven that following this route is the best solution.
At Z1, we offer workshops where we explain our process. The blockframes phase is usually a revelation among the attendees, mostly product designers, because they identify it as the phase they need so badly as a starting point. We also advise them about how blockframes allow us to organize our week and clearly see what we have time to do every day. In addition, anyone joining the project, be it a product manager, developer, or content designer, will know exactly what has been done and what still needs to be done without anyone having to explain it to them.
“Blockframes allow us to organize our week and see what we have time to do each day.”
In conclusion, the blockframes phase is ideal for gathering the input on requirements we need from the clients and validating what we will work on. It’s also an effective way of avoiding going out of scope and having to iterate when we are at higher fidelity phases, which will suppose more effort.
They are, after all, a clear graphic structure on which to build an enriching dialogue between design, product, development, content, and clients. A pragmatic and straightforward system for designers to identify the dots on the blueprint where more information is required and move forward efficiently to achieve the best results.
Join us for a monthly dose of digital product design, juicy inspiration, and useful tools.