John Romano
BlueOak Design
John Romano
December 22, 2016

BlueOak Design Libraries: Where Design Patterns Meet Dev Frameworks

There’s a lot of pressure on mobile design and development teams to both innovate and reduce costs while working at speed and scale. These pressures are driving us to:

  • Spend more time creating high-value features that will differentiate an offering
  • Spend less time building common functionality (recreating the wheel)
  • Optimize the way teams work together to increase velocityBlueOak Value

These pressures are part of what’s driving the creation of new libraries and frameworks. On the development side, HTML/CSS/JS libraries like Foundation and Angular have become the norm. The pressure on the design side has led to design patterns (like Brad Frost’s Atomic Design Library) and style guides.

The problem is that HTML frameworks (for websites and hybrid apps) and design libraries are often still too siloed. In large businesses and consultancies, being siloed leads to misalignment.

Development libraries have technical documentation, but often lack tools for designers. User experience designers (UXDs) create wireframes that have to be entirely redrawn in layout applications by visual designers – who create specs for developers that don’t relate to the development libraries that products are built in. Everyone is using different tools and speaking different languages. This often leads to rework, frustration, missed opportunities and miscommunication.

If we want to increase velocity and optimize team collaboration, we need to align each group’s work with one another. The deliverables they produce need to dovetail together. Equally important, we also need to create a consistent language that everyone can speak.

Unified UX, Visual Design and Development Libraries

So, how would a unified library that provides tools and standards for UXDs, visual designers and devs improve the website or hybrid app build process?

Common toolsets eliminate rebuilding the same element over and over.

Developers have bought into frameworks as a way to increase their velocity, but frameworks on the design side have huge benefits as well. For instance, drawing a simple button might require both the UX and visual designer to each

  1. Draw a rectangle
  2. Set stroke, fill and corner radius
  3. Create a text field
  4. Edit the text
  5. Set the text color, size and alignment

Why not drag a pre-styled button from a tool box onto the canvas? This doesn’t mean designers can’t change it if they need to. But prebuilt libraries create consistency and speed up their work. They spend less time doing manual clicks in their program and more time thinking about larger design patterns.

Common documentation would benefit everyone, not just developers.

We know common CSS documentation helps developers, but it would show visual designers what is available and what style attributes they get for free (without developer customization). This begins to inform them of the “cost” of their design decisions. It helps them identify ways to achieve the look they want and focus the developers time on what matters.

Common language improves team communication.

Is it an “off-canvas menu” a “slide-in menu” or a “slide-out menu?” Do they use an “overlay” or a “modal?” How does it work on a mobile phone? Having a set of default names and behaviors helps designers and developers speak to each other. It eliminates confusion and reduces re-dos, improving velocity and improving team communication.

Page layouts help structure applications.

It doesn’t stop with the individual elements. A common layout framework can help align designers and developers to quickly structure responsive page layouts. Having a set of defaults lets people make accurate assumptions and makes people think about if and why they want to change.

The dream

Let’s imagine a situation where UX, visual design and dev are all working from a common library of default elements. Imagine a UXD placing a button in a wireframe. Now imagine if that button also exists as a library element in the visual designer’s layout tool and in the developer’s framework.

So (by default) a button is a button in:

BlueOak Buttons

Next, imagine if the visual designer knows that he or she can, with little effort, customize specific attributes of that button (say the fill, stroke and radius). Now, if they want a custom rollover effect, they are more aware that it will take extra time (i.e. burn more project budget). It makes the designer think “is this an important effect on a critical button, or is this something to do if there’s time.”

Introducing BlueOak Design Libraries

We’ve released the BlueOak design libraries to complement and extend the BlueOak front-end framework and BlueOak Server. They are based on Foundation, a leading CSS framework.

BlueOak Design Libraries

They provide UX and design production tools to help unify your marketing/design and IT teams. So far, we’ve built:

Axure Widget Libraries

Components – the foundational elements for mobile apps: drawing shapes, typography, buttons, content elements, navigation, forms, menus, modals

Flows – similarly styled flow chart elements

Grids – screen elements and multi-column layouts for phone horizontal, phone vertical, tablet horizontal, tablet vertical and desktop  

Callouts – A call out library for UX documentation

Illustrator Design Template

Components – UI elements for mobile sites and apps: drawing shapes, typography, buttons, content elements, navigation, forms, menus, modals

Sketch Symbol Library

Components – a Sketch symbol library with UI elements for mobile sites and apps: drawing shapes, typography, buttons, content elements, navigation, forms, menus, modals

An example

Here’s a sample of how these unified elements can take you from sketch to a basic visual design.

BlueOak UX Example

On Innovation

Innovation can be a delicate flower. In the right conditions, it can flourish, but it can be easily crushed. We always have to be on the lookout for new processes and tools that can help us be stronger, more effective teams. Let’s make sure that our tool sets don’t chain us down.

We always need to be looking for ways to evolve our tools and approaches – or to replace them all together. We can only do this by giving every team member the freedom to try new things. Encourage experimentation. Enable people to give back or to improve these libraries.

Remember to focus on the end goal, not the rules.


Filed under:

If you like this, you'll like these:

More Blog Posts