Designing in-medium is not as difficult as you fear
Originally written for and published by Third & Grove (May 5, 2017)
It seems the common response to "Why not design in-medium?" is always some variation of "That'd be great! But then our designers would need to know how to write HTML and CSS."
First, a disclaimer: We are not getting paid by Webflow. I wish we were, but we aren't. In fact, we've yet to see any other agency or individual using Webflow just for UX prototyping and as part of the design iteration process for larger, complex projects. It is a service vying for ground in the easy-to-produce website service arena, competing with the likes of SquareSpace, WordPress, and even Wix. However, unlike SquareSpace or Wix, you start with a blank sheet and design nearly exactly as you would in Adobe or Sketch. And unlike WordPress, you don’t have to build a website instance or have knowledge of the development process.
You could just force all your designers to start taking classes at Treehouse or Codecademy, but I’m willing to bet you’d be scaring your resources, as well as misappropriating an already well-functioning resource as-is. My point is not that designers are designing badly. Rather, it might be time for some of us to throw away our old tools and adopt new and improved ones.
If you are not convinced yet that this retooling is worth it, here are some of the biggest reasons why in-medium designing, and Webflow as that tool, are game changers for us, and why the usual static workspace serves us no longer:
A GUI interface that forces the designer to think in web variables and values
- If you can build it in Webflow, your engineers can build it in their final environment. Working in-medium forces the designer to think more like an engineer. This exposes the designer to a dimension of the product they may never have considered or seen before. This perspective brings new levels of understanding, as well as new levels of ideative solutions for your products.
- In Adobe, when you set a font size, you set it in "pt". When setting the space between lines, the palette field is referred to as "leading". In Webflow, the designer is guided to think in the same nomenclature as your engineers: "font-size" is set in pixels, rem, or em; "leading" is "line-height". These small adjustments in how designers build make a huge difference for engineers. Designers of digital products cannot speak the same language of designers of print products. Our teammates aren't press techs or publishing houses, but engineers. We must speak like engineers. Rem versus em is a confusing concept to digest, but there are countless resources online that will help clarify nearly any query you may stumble upon.
- Sometimes getting behind the curtains allows you to think of alternative ways to build empathic, widely accessible products and environments that can get your product closer to a AAA rating. This is harder to do in static workspaces, simply because we are not thinking of this kind of tertiary logic while in flat file environments. This means consideration for Section 508 or WCAG compliance ends up getting a back seat, or a measly single line of notation on a spreadsheet for content entry.
Harder Easier, Better, Faster, Stronger
- How many of us have had to explain to clients that a wireframe is not meant to be visual, but that it is still visual to some degree: "Yes, your logo could go there, but no, the buttons don't have to be 1px black strokes." This misunderstanding was so prevalent back in my early days of practice that I added a descriptive line to every wireframe page stating that the document was not meant for User Interface review. That is a hard concept for a non-creative to wrap their head around in the first place.
- Skip the wireframes. Skip the half-baked visuals. Build your wires with legit iterative skin around them. Consolidate the structural and skinning iterations in one go. This will allow the client – and even your own team – to interact with a more complete product experience versus some high abstract concept that needs to be pushed and pulled around a skeleton that was built separately.
- Get your user testing involved earlier. Back in the early 2000s, designers were user testing with paper and pencils. If your product had a Twitter API, we'd cut out a small slip of paper representing a tweet, and when a user tapped the paper device before them, we'd slip the corresponding action (like a tweet) right under their fingers. Sounds silly? Now, years later, it does sound silly. Aren't we doing a mere toddler's-growth version of that same thing, working with static screens of one interaction flowing to another? With in-medium prototyping, you can build this interaction in. It may not be a literal action connecting to an API, but one could build it in such a way that the user has no idea of the difference in the back-end. (Note: Although this isn’t an easy task to custom produce in Webflow without using their un-style-able defaults, it is absolutely possible – and worth it – to get this kind of functionality with the help of your FE+BE friends and the Embed Object.)
Endurance 'til the end
If we were at a conference, I'd rhetorically ask those who've gotten an “endurance Charley horse” to raise their hands. I'd be so sure that this is a common concern for designers that I wouldn't need to look up. Just like muscle fatigue, designing comes with its cramps and endurance limits. Working on the same iterations over and over and over again can cause a good bit of frustration, especially when you've strived to base your ideation and iterations on hard and fast data and research, only to be rejected for reasons that are nonsensical or not within your range of understanding. I don’t profess that designing in-medium will solve this entirely, but it does ease workflow and workload by noticeable measurement.
- Limit iterative strain with inherited properties (inherent in the medium). Somewhat similar in concept to Adobe’s Object Styles or Sketch's Symbols functionality, setting up global styles in-medium helps you reduce production effort, time, and strain, even through countless iterations/versions.
- Colors, sizes, and other object/element styles change as your product goes through the appropriate funnels of critique > revision > refinement. In a static workplace, this takes production time. After several revisions, aligning all those boxes begins to fall by the wayside in an effort to reduce churn or meet a deadline. If you have symbols set up, that's helpful, but there are properties in HTML/CSS that allow for a smoother adjustment for fast changes to broad rules: font-size, font color, leading/line-height, kerning/letter-spacing, link styles, and even spacing of objects. These properties will be compatible and easily extractable from your in-medium environment to dev with little question about what your design meant.
And there was peace in the land of devOps
- Speak the same language. Stereotypically, there are misconceptions in our industry: that designers think engineers are stubborn or put more impetus on performance/entropy over the user, and that engineers think designers are frivolous, aesthetic-zealots, unconcerned with bloated pages. It's kind of true. When both parties aren't communicating in the same language, desires and concerns become the last subjects in a dialogue. In-medium brings designers closer to the engineering environment.
- Use the same body language. I'm a typographer at heart, and one practice that fellow front ends have come to expect from my styles are -1 to -3 pixel margins on headers, or -.02em to .02em letter-spacing everywhere. What designers who are unaware of true web language strive to do in static workplaces (such as optically aligning bodies of text) is not always obvious to engineers. This is not their fault. We as designers were taught to hone our focus on the balance between minutiae (for refinement, ambience) and macro (messaging, voice, brand). It may be obvious to us, but we shouldn't expect it to be so for everyone else including our clients.
- Now that you saved hours and effort in the beginning UX phases for design, involve your designer as a support entity for your engineers during devOps. This will allow for progressive, evolution-based refinements, as well as for solving surprise bugs. Resourcing a designer in devOps is tantamount to achieving high fidelity final builds.
Stop making your engineers guess what will happen between breakpoints and interactions. Comping three versions of your pages for desktop, tablet, and mobile is not enough. In fact, there are actually four major breakpoints. This include desktop, tablet, mobile landscape, and mobile portrait. How every single one of your elements flex and adjust to and between those breakpoints shouldn't be left up to your engineers to guess. To be a true responsible and responsive designer, you must take control of these kinds of aspects of your products. Simply saying: "I want those tiles to go from 4 columns to 2 columns on tablet" doesn't account for the entire experience. What about the animation of widths adjusting? Will the padding and margins change? Will this happen for all columns of 4, or just a specific spot? These questions can go on for line after line, and this is not what your engineers should be resourced for.
- Many leave the above point for UAT (or, slightly smarter, user testing). It should be obvious how dangerous and budget-bursting that strategy is. Even if your product isn't particularly complex, your client in UAT has a lot to juggle. Expecting them to catch and comprehend everything inherently and with enough energy to respond appropriately is asking too much. Our job is to proffer, not offer, solutions.
Last, but not least
Send your clients, both current and prospective, home with their UX prototypes. Designing in-medium means that the product is responsive, compatible with most (if not all) browsers (which is very easy to do in Webflow), and live. Pop a password on your prototype and share the URL with your proposals. When you’ve nabbed that project, send the stakeholders home to truly consume all aspects of the UX on their various devices exactly as the product is meant to be consumed. Perhaps that nonsensical request may make less sense when they’re using the product in context. Or maybe it is you, the designer, that will notice the reason for that “nonsensical” request when trying to impress your next Tinder date by showing off your latest project prototype. ∅