As software designers, we have more tools available than ever before to help us design beautiful software and rich interactions. However, I believe we are still in the infancy of design tools, and would like to offer several ideas for how they can mature and evolve to better enable us to create digital experiences.
Hopefully, and if helpful, these ideas will inform the tools we build in the future. These ideas should be taken, built upon, and improved to the end that we as designers will have better tools with which to create better software.
In this article, I’d like to explore an opportunity to improve one fundamental aspect of design tools: layouts.
We live in a world that is dynamic, designing and building software that lives on devices that are always changing and evolving. These devices have multiple screen sizes, densities, orientations. Our experiences live in this medium, and adapt to ever-changing constraints. This leads us to an important principle:
Design tools should have the same properties as the medium for which we are designing.
Today’s design tools are far from this. Photoshop’s primitive is a single, fixed-size raster document, harkening back to an age where designs mostly lived on the printed page. Sketch improved this slightly with vector artboards, allowing you to design for multiple screen sizes and devices in the same page by using multiple artboards. However each artboard is still a single, fixed size. What’s more, objects in these tools all have a fixed sizes and locations as well. Text labels, images, buttons; everything is static. Becauseour tools are static, we tend to think and design statically for a single screen size without considering how it will adapt to various constraints. Simply put, our primitives are wrong.
An Adaptive Canvas
Let’s take a look at how a modern design tool might work for designing an iPhone app. This tool is simply a straw man intended to be communicate an idea and provoke thought.
We first need to fix our primitives. The vector canvas should be adaptive, meaning the size isn’t fixed, so we can design in and for all the screen sizes and orientations our app will eventually live in. Something like this:
We can now start to design how the layout and each object should adapt to changing constraints, in addition to how they should look. Both Android and iOS have rich layout systems; so too should our design tools. Making intentional decisions about these layout constraints is part of the designer’s job, and allows us to spend time crafting these seemingly small details that are often overlooked, but can add up to a better experience for our users. What’s more, it helps us think in terms of implementation, making collaboration with engineering easier, faster, and better.
Notice how quickly an adaptive canvas brings up questions that we have yet to answer: how should this work on different screen sizes? What happens to these objects? How do they adjust? Does this make us reconsider anything?
Adaptive Layout Objects
Our canvas is adaptive; so too should our layout objects be. By bringing in many of the concepts found in, say, UIKit’s auto-layout, we can now start to think about the behavior of our objects and how they should adapt. With a few simple concepts, such as size, alignment, and pinning, we get a layout system that allows objects to be adaptive relative to each other and the canvas.
In the below example, notice how fast it is to add layout behavior to objects. The logo should always be centered. The search input should grow in width, but always be pinned 16pts from the left and right edge of the canvas. The weather card should be -90pts pinned below the bottom edge of the canvas, always showing a small preview.
With just a bit more work, we end up with a fully adaptive layout. Since software design is almost always a team sport, a modern design tool would let you share this with anyone easily so they too can see how the layout adapts. This would be especially useful when collaborating with engineering. The ability to inspect each object’s layout constraints would greatly reduce the need to spec or redline static mocks, and make the implementation process far faster and easier than it is today.
One area where a tool like this would be particularly useful is making decisions around how our layout should work in landscape mode. Many apps choose not to support landscape mode, as there is an additional cost in both design and development. But for those apps that do, an adaptive layout system allows you to quickly optimize your design for both portrait and landscape orientations, creating the best experience now matter how a user decides to use your app.
In this example, we can make some interesting but important decisions when optimizing for landscape:
- Do we need the status bar here? Let’s remove it.
- We have much more horizontal room now, so let’s make From and To, and the ETA and Route inline.
- Once we do that, we can now greatly reduce the space the header and footer take up, allowing us to see more of the map.
Since our tools shape our thinking, it’s critical that we have design tools that allow us to go beyond the static thinking that has encumbered us for so long. While it’s technically possible to design and optimize for various layouts and orientations today, it’s tedious and difficult, which means that we often don’t do it.
The age of pixel perfect design for a fixed size is over. The number of devices and sizes our designs will live on will continue to expand, and so too should our tools.