In this Maker Series event, Dan Mall treated us to his unique brand of inspiration, ideas, transparency, and real-life project examples that we love. In the morning session, Dan focused on laying out a framework for web designers to use when working on a project. It was so valuable to see this framework in the context of projects that Dan has worked on and to get an inside look at his approach. As is true for Maker Series events, Dan spent the afternoon addressing questions from the audience, which included pricing (hey, did you know Dan has a book on pricing coming out in the spring?), approach, client management, and a ton more.
The Framework
The designer’s framework that Dan walked through was not meant to be a rigid process to follow. (Hello, you say, that’s why it’s called a framework). I love the metaphor he uses of a newton’s cradle representing a rigid process vs. a soccer field that represents a framework. A newton’s cradle is a linear device that represents a rigid process. One ball swings, which hits the next, which in turn transfers energy through the other balls into the ball on the end making it swing and so on. A soccer field and its accompanying rules represent a framework. There are many players on the field, all trying to accomplish a common goal, but there are many strategies and techniques to accomplish that goal. The field serves as a framework that contains the actions of the players.
We should emulate that concept of a soccer field when we design and build for the web. Here are a few ways that we can begin working within this framework.
Designers Need to Plan
In order to gather needed information that will inform and help us make decisions on the products we build, we need to spend the time talking to users and stakeholders and distilling that data down to help us form a plan for the project. That plan should be written in the form of a manifesto (or sometimes called a creative brief) that will serve as a guidepost for the project and be referred to as decisions during the life of the project need to be made. It will ensure that everyone is working on the same project. The manifesto should contain project goals (ex., what you’re going to do, what you’re not going to do, your point of view, and the planned approach on the project.
Having worked on a couple projects that use a manifesto, I’ve seen how valuable these can be in a couple of ways. First, it keeps the client focused on the goals that were determined at the beginning of the project. Clients tend to want to stray off path at times, and pointing them back to a document that clearly states the goals helps keep everyone on the same page and make decisions with the end in mind. Also, it helps me as a designer to make conceptual and visual decisions. I can ask myself, “How does this concept support the project goal of _____?”
Designers Should Do an Inventory
A few different types of useful inventories were discussed (a visual inventory, an interface inventory, and a performance inventory).
A visual inventory could be a collection of images and examples of inspiration for the project. It could also be a collection of websites that you simply place the client’s logo onto and have a discussion about which examples feel right.
An interface inventory is something that could be done internally in the middle of a project. Atomically speaking, it’s making sure the atoms, molecules, and organisms are visually consistent. By breaking the site up into small pieces, we can easily spot inconsistencies and maintain the code in an efficient way.
A performance inventory, or budget, is a great way to identify how much “weight” you can afford to have on each webpage to achieve the speed you want. Once you establish that constraint, you can play within those bounds to figure out how much space you have for web fonts, HTML, JS actions, and so on.
Tim Kadlec talked about performance budgets at length in his Maker Series event this past Spring. Our own Katie Kovalcin has written about the subject—as have Dan and Tim—and does an awesome podcast with Tim called The Path to Performance.
Designers Need to Sketch More
The term “sketch” doesn’t just mean a hand sketch or doing quick Photoshop layouts. It also isn’t just meant for the beginning of a project. Dan’s point was that designers need to use the means available to explore visuals and communicate design language to the client. This could take many forms such as using Typecast to explore font combinations, creating Element Collages, creating visual “hooks” by writing, or using hand-sketches or whiteboard sketches. I’m sure there are many other possibilities that could be used here too.
Designers Need to Prototype
This was less about the tools (though tools were discussed) and more about the process of prototyping. Dan believes that as designers we need to build or work with a dev to prove out functionality of concepts that we come up with when it makes sense. He showed some great examples—some of which took some explaining—of these kinds of prototypes. Dan laid out three rules for prototyping from his friend Jamie:
It must take less than one hour.
The first one should be something anyone can build.
Build ugly.
Quotables
A couple of quotes from the day that I loved:
“Let’s not design in the browser; let’s decide in the browser.”
This quote is one that Dan started saying a few years ago, but it still strongly resonates with me. I love how it communicates that design needs to be thought through before we get it into the browser, but that doesn’t mean it’s finished. It can still be iterated on once it’s in the final medium.
“Make the subjective objective.”
This was a tip that Dan gave about presenting design concepts to clients. Design can be very subjective, but communicating why you made the design choices you did to a client makes them objective. Be sure to communicate how your design decisions address the goals of a project.
Get in on the Learning
As always, it was so inspiring to have Dan share his experiences and ideas with us, so we are sharing it with you. Here is the video of Dan’s Maker Series presentation and collaborative notes taken by those present at the workshop.
