Designing with Meaningful Data

The way we approach designing with data has changed over time and is still evolving. An observation.

There’s a lot of buzz around a new Sketch/Photoshop extension called Craft by InVision LAB — and rightfully so! I think they built a great tool that makes using mock data early in the design process more accessible, tangible and convenient. Craft is the new benchmark for Sketch plugin user interfaces. Their custom panel enables direct manipulation, WYSIWYG-like treatment for mock data. It also features a straightforward built-in interface to extend sample data by copy&pasting flat text files. Clicking on content blocks of existing websites to pull their data into your own design is another practical approach.

Accessing all these features through a custom UI appeals to designers. It caters to their habits and comfort zone. It’s just like it should be, it integrates well into the tooling world designers know and use every day. It’s a lot of fun to use and it’s rewarding to see screens and components come alive with ease.

Data in the Era of Designtools

Craft also has an interesting strategic dimension: it puts pressure on both Adobe and Bohemian Coding.

Adobe started talking about a new initiative they call Project Comet, which is widely considered as the first actual threat for Sketch since its first appearance (Sketch has become a serious rival for Adobe’s tools). And what Craft does looks a lot like parts of it — well, it’s actually the same. Adobe calls it realistic data samples, InVision real data samples. But Craft is out there now as a tool that many designers around the world already integrate into their existing design workflows.

And why does it put pressure on Bohemian Coding? Fluid for Sketch was the first plugin I know that came with its own toolbar and inspector panels within Sketch. Now there’s Craft, plugging in its own custom panel and even a main menu item.

Extensions like this show that there is a growing need for Sketch to think their extensions ecosystem further. Developers want to implement custom UI elements that integrate consistently. Users do not want to be confused by overlapping shortcuts. They expect reliability not only from the core of the application, but also from extensions.

It’s a huge opportunity for Bohemian Coding to work out a more versatile and more defined ecosystem together with a very active and loyal developer community. Sketch is in the position to boost the era of the design toolchain once they start offering better strategies to connect tools easily. Craft’s popularity does a great job in making that more visible.

Real Data? Really?

Do you remember when Photoshop offered a “Paste Lorem Ipsum into selection” command? Back then, it was a lot of effort and hassle to use meaningful content assets. Designers were lazy — or had better things to do — and ended up with a lot of repeating identical elements. To fight boredom, a refreshing approach emerged: they started using either stock material or celebrity pictures and names as placeholder imagery. No matter what context or meaning those beautiful faces had in their screens, they mostly lived in Los Angeles (or in sparkling clean surroundings).

At some point, the absurdity became apparent. The need to use real people increased, which led to approaches like Facebox (RIP) or similar libraries. Some design teams even created their own custom collections to fit with their target audience. And then, Sketch Content Generator appeared on the horizon. It allows to select elements and automatically fill them with realistic content like profile pictures, names, contact details and more.

It brought a huge boost in productivity, but wasn’t fully satisfactory. While it became quick and easy to replace dull placeholders with random mock data, the content remained unconnected — there are no meaningful datasets of entities, eg. choosing a female picture leads to a female name, and an email address, city or country that make sense regarding to this name etc.

It does not really stimulate investigation with the data as the material for our screens and components: the content is being taken for granted, as long as it’s flowing in like magic, from an inexhaustible source. Select, generate content, repeat.

From Data Depth to Surface

When we at precious design studio started conceiving a better, deeper approach to designing with data, we never had in mind to make our lives as designers more easy and convenient. The opposite is true: we wanted to challenge ourselves. We wanted to learn more about data structures, how algorithms tick and APIs work. We didn’t want to settle for replicating fabricated surfaces by scraping existing websites. We wanted to start exploring data as raw material. We believe that’s one of the most important challenges for designers.

I personally found it to be an interesting question how studying and trying to understand data structures in the form of JSON or playing around with APIs would influence what and how I design. How do data structures define (or challenge) the way I think and build layouts, modules and their dependencies, navigation and interaction patterns? But also, does it influence the way I structure and organize my Sketch files? Does it even question the use of Sketch?

Is there something hidden inside the raw data material that I can carve out and make visible and accessible on the user interface? Is there a difference when using flat or hierarchical data, or a graph structure?

This is when we started to develop Sketch Data Populator as a way to populate JSON data to the structures we use within Sketch. We started going through content architectures of existing projects, explored some of the popular APIs like Twitter, Instagram or Spotify and played around with services like import.io, Kimono or mockaroo.

Like this, we enabled ourselves to use our own data sources. We could use the data to tell comprehensible stories by using consistent datasets — data belonging together in a defined and reliable way. Realistic data became meaningful.

Data as Design Material

The enlightening part was not the variety and richness this access to a plethora of data sources offered. It was the exploration of the actual material we work with — trying to understand and manipulate the JSON structures and thinking about the consequences it has for the surface we had designed in Sketch. And at some point realizing how much it’s not about designing an ideal surface and populating it afterwards, but more letting the content and data structures inform and drive our design decisions. On a high level, “form follows content” was always clear and self-evident, but working with JSON and Sketch Data Populator brought it to the tool level, providing an immediate benefit to our everyday design practice.

After working with Sketch Data Populator on an everyday basis — and extending it and making it better together with a very productive bunch of contributors, we experienced more and more limitations. We think a lot about improving its UI and making the data literacy approach more tangible. In this context, we often ask ourselves how to make Sketch Data Populator more data driven, instead of just populating over existing visual element structures. How can we “consume an API or JSON file and visually inspect its contents”, as Josh Pucket writes in his widely spread article Modern Design Tools: Using Real Data. How can we manipulate and transform the data in real-time, populate in Sketch, do more manipulation, re-populate — and ultimately become API architect’s new best friends by becoming so much more aware of the user’s data needs and requirements.

Designers need to make sense by shaping and iterating the underlying data structures, not just the superficial Gestalt of a product. We have a lot of ideas we already started thinking through and sketching out, but there’s still a long way to go …

Design shapes Data shapes Design

Adobe’s Project Comet as well as InVision’s Craft are great tools for designers to move beyond Lorem Ipsum. But they do not offer an answer to the increased need for data literate designers, yet.

To become better designers, we need to leave our comfort zone, dive into worlds that might look daunting from the outside. When thinking about designing with real, meaningful data, we shouldn’t look for convenience. We should always strive for challenges and use our curiosity to comprehend the growing complexity that surrounds us.

In 2016, the notion of designers learning to code is outworn — it’s about designers becoming data literate.