Skip to content

Instantly share code, notes, and snippets.

@jeromecoupe
Last active May 10, 2016 14:11
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jeromecoupe/b33803ce1f34dd295fa63a7d535e4c14 to your computer and use it in GitHub Desktop.
Save jeromecoupe/b33803ce1f34dd295fa63a7d535e4c14 to your computer and use it in GitHub Desktop.
Outline for the Creative Meeting introduction @ Base Design - May 11, 2016

Communicating design in a digital environment

Before getting into the matter, I wanted to set the stage. We are essentially going to talk about three things today.

  1. The context of digital design
  2. Problematic static design deliverables
  3. Design deliverables and the current digital workflow

The context: dealing with unknown unknowns

Digital designers have very little control. We have had to learn to accept the ebb and flow of things

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things”.

“[A Dao of Web Design](http://alistapart.com/article/dao)” - John Allsopp, 2000

Or, as Secretary of State Donald Rumsfeld would put it quite eloquently.

As we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know.

“[News Briefing](https://en.wikipedia.org/wiki/There_are_known_knowns)” - Donald Rumsfeld, 20O2
  • unknown canvas: proliferation of screen sizes and devices. We have to work from the inside out, start with the content, design systems of fluid components and not pages
  • unknown device and browser capabilities: browser, bandwidth, support for images or videos, support for CSS and javascript, geo-localisation, etc
  • unknown user context: web can define our users through personas, etc. but the truth is that the user context largely remains unknown to us.

Problems of static design deliverables

Problem: takes too much time & effort

If you were to use static design comps in 2016, you would have to design a couple of version of the homepage and of a key page of a website in at least 3 different resolutions.

At the minimum, we are talking about 12 comps for just two pages. Multiply this by the number of page types in a digital project and it quickly become untenable for most agencies, freelancers and clients in terms of time and budget.

Problem: Do not take into account the specificities of the medium

These static comps cannot represent essential aspects of design in a digital context:

  • design interactions and states (hover, drop down menus, animations, etc.)
  • design for a wide variety of screen sizes and resolutions and what happens in between.
  • design for the capabilities of the devices: JS support, CSS support, browser versions, etc.

Static comps present the design in a totally different context than the final one, which is the browser. The typefaces usually render differently in Photoshop or Sketch than in the browser. The client sees the whole design at once where, in a browser, only part of the design is visible at any given time, etc.

Problem: Introducing a divide between design & development

Static comps introduce a disconnect between the design and the code as a mean to bring the design to life.

It hampers the dialog between designers and developers instead of promoting it. Design should inform code and code should inform design. Certain designs are not possible in code or require to jump through so many hoops that the accessibility or performance suffers. Certain possibilities of code can inform design or become a central concept of the project.

Examples of design concepts built around code techniques: Works and Co navigation scheme, Nurture Digital, The ballad of Geeshie and Elvie etc.

Solution: Where are we today

If design is about solving problems, it means that design is about having the right conversations with our clients to see what their problems are and come up with solutions.

We all have to make money and are selling our time and expertise.

We have to focus on design deliverables that:

  1. take into account the “ebb and flow of things” in the digital design world
  2. will cost us a minimal amount of time and effort to produce
  3. will help us to have the conversations we need to have with our clients

Communication is paramount in the design process and our deliverables have to facilitate it, both between team members and with the client.

“You must also address the very human issue of communication. Earlier and more frequent collaboration among team members and the client must become the rule in your workflow, not the exception. Content, design, and development team members must review and collaborate regularly at every stage in the creation process until the site is live. We can’t ‘throw it over the wall’ anymore— at least, not if we want our sites to be excellent. There are simply too many moving parts now. Go forth and collaborate.”

"[Design Process in the Responsive Age](https://www.smashingmagazine.com/2012/05/design-process-responsive-age/)" - Drew Clemens - Smashing Magazine

Digital workflow & examples of deliverables

Design explorations

Visual inventories & exercises

These are not really novelties but are interesting to use in a digital context. Dan Mall proposes to work with visual inventories during the exploratory phase. By presenting several existing designs / websites and asking very targeted questions, Dan gathers valuable information to quickly establish a design direction.

Brad Frost argues that small workshops with the client gives you the opportunity to play games such as the “20 second gut test” or “website user feelings” that will bring other insights to the table.

With only a few hours of work, you can have the right conversations and establish a clear design direction without even touching Sketch, Photoshop or Illustrator yet.

Style tiles and element collages

Style tiles are a method developed by Samantha Warren while at Twitter. These small design compositions are really quick to produce and can be a relly good tool during the very early stages. They aim at gathering insight and kickstart a conversation to establish a design direction.

Examples: Sparkbox, A few examples on Pinterest

I personally work with element collages as described by Dan Mall and Clearleft. These are a series of interface and content elements presented as a patchwork. The idea here is to present a general look and feel for the project, we don’t have to design everything. I generally present them horizontally so clients can see that it is clearly not a website but that it can become one.

Examples of elements collages: (Equal Partners, Tramway21, typecast)

These deliverables are quicker to make that a series of comps, allow the designer to present and discuss the design system (colors, typography, iconography, components, etc.) without getting at the page level. Their very nature also introduces the fact that we are not designing pages, but a modular system of components.

As a designer, you might need to see how these various elements you design look when combined together into a page. By all means do so. Just pick a couple of key templates (not more or we are back to comping all pages in all resolutions) and test your library of components by combining them to create those pages at different screen sizes.

Those comps should never be shown to the client for sign-off, though.

The trick here is not to never do full comps, it consists in shifting the client deliverables and your goal as a designer from comps to an element collage. Full page comps are not the outcome of the design process, but they can be a byproducts of it. As a designer your focus is on designing a responsive and flexible system of components, not pages.

When the client will finally see the website or the application, it will be the outcome of an iterative and collaborative process, not the proverbial Don Draper “big reveal”.

Interactive (HTML/CSS/JS) prototypes

Some elements need to be communicated using interactive prototypes (HTML/CSS/JS) in the browser. Generally those are limited to very specific aspects like complex navigation interfaces, specific animations or interactions that only make sense when presented in the browser.

When working both online and offline as Base Design often does, these quick prototypes will complement element collages nicely, allowing you to test that all parts of the identity are suitable for digital platforms. Are the fonts you chose available for the web ? Do these fonts work at small sizes in interface components in the context of an application ? How does the chosen color palette look on screen ? Did we take into account the wide variety of screen sizes and resolutions is all aspects of the identity ?

These code prototypes should be minimal and remain quick to produce, we just use code to test our design assumptions and validate our design decisions by taking into account the digital context. Using Photoshop to frame pretty images into screens of a Macbook Pro or an iPhone 6S does not quite cut it.

Production phase

When we have agreed on a design for the application or for the website, we can go in production.

Style guides and pattern libraries are all the rage these days and for a good reason. They are the best way to present modular design systems in the context of the end medium. They also foster collaboration between designers and front-end developers. Pair designing is the new black.

Examples of elements style guides and pattern libraries (BBC Gel, Code for America, Salesforce's Lightning, Google's Material Design Lonely Planet, United States Government etc.)

When we have to build the page, we can combine macro elements (templates and grid systems) with micro elements (components) to create all the pages we need.

Post-production or maintenance phase

The difficult thing with style guides and patterns libraries is that they can sometimes become stale and quickly resemble a ghost town if they are not maintained and used.

Engaging in a style guide driven development process helps avoid that kind of problem.

The best way to enforce the use of a style guide and make it a living thing is to embed the style guide in the production environment. If you use a CMS or a framework, your style guide should ideally live in there alongside your production code.

Salesforce UX are doing a lot of work on design systems and how to implement and maintain them.

@stevepiron
Copy link

Very good for a first pass! It's a quite thorough dive into the subject while at the same time kept short and to the point, which I think is very good for the outline or "theory" part. I like how you introduce those concepts with assertion as it will obviously foster questions and discussions and that's where use cases come into play.

I think we could go a bit further than this kind of generic approach of redesigning a website and take into account the fact that Base Design usually steps in the digital world after having designed a brand identity with (some kind of) guidelines applying to pictures, iconography, typography etc. Even worse, some clients even receive one or two digital, laptop-sized digital comps alongside their brand guidelines to show and prove "with such an identity, this is how your website could look like". This has always seemed wrong to me, especially as it is often just one designer doing its thing, designing a "page" comp all alone with little to no experience designing for the web. It goes without saying that interaction, mobile UX (and many more points) are obviously left alone, only to please the eyes of the clients who will agree on visuals that his website will indeed fit the brand identity that has been developed.

...and 2 months after, things break. Client doesn't understand why we step back and change this and this and that.

What about those custom typefaces or foundries that don't offer webfonts? Loading 2 typefaces, 4 weights each? Control over line length and line break? Image ratio (e.g. the new Base Design picture which on mobile will be 100% wide... but 20px tall?)

There are many many points to tackle but that being said, let's stick to "better design deliverables" for now and hopefully they'll dig it enough to ask for another round. And I know they will!

Good job J!

@jeromecoupe
Copy link
Author

From Delphine: I still think it is important to be able to see all the different components together, to see if they work next to each other.

@matthiasdeckx
Copy link

matthiasdeckx commented Apr 25, 2016

Strong introduction as it is to the point in stating the problems and why they're an issue. It's also easy enough to understand for someone less tech-savvy.

The first solution (Visual inventories & exercises) is not something that's unique to a digital workflow, but can just as well be applied for print or brand exploration, so I have mixed feelings whether it should be in there.

Also agree with the previous comment by Delphine. It is still necessary for both client and the designer to see the different components together to have a good example of how a page would look. So in that case you're not really saving time anymore.

Something interesting to talk about is when the focus on digital design should start in the process of creating an identity, which should of course be as early as possible. This is a useful discussion at Base, as most projects are complete (re)brandings. Obviously this is still too much of an afterthought in a lot of agencies. F.e. when font decisions are made: Did we check whether these fonts are suitable for web? When type and colours are chosen: How should these colours be used in an interface, how should the type be used in interfaces and does the font work for buttons, form fields etc.? What about image ratios on web when you constrain their ratio in the guidelines, but obviously want the best translation from off to online? These things should not be an afterthought.

Note:

The typefaces are usually widely different in Photoshop or Sketch than in the browser.

I assume you mean the way type is rendered can be different than in the browser. If so, this should be slightly rephrased to clarify this.

Anyhow,
Good work Jerome!

@jeromecoupe
Copy link
Author

Thanks for the feedback everyone. made a few changes addressing your comments. See Style Tiles and Element Collages and Interactive Prototypes for details.

Also added a bunch of links in there.

@matthiasdeckx
Copy link

Another example to show:
http://devbridge.github.io/Styleguide/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment