Benefits of Style-Guide-Driven Development


Living style guides are increasingly popular front-end development staples. Integrating a live style guide into your process streamlines workflow, promotes ongoing design cohesion and provides a simple way to visualize how style updates will impact elements site-wide. Above all, living style guides improve collaboration and team communication, resulting in better digital products.

Design Cohesion

The great thing about digital products is they’re never truly complete. We’re always iterating to add features, update resources and improve user experience. Through its life, a product may change hands, with multiple designers and product owners. Over time, this can lead to a mishmash of design elements, with older areas of the product overlooked as new areas receive a facelift. A living style guide helps ensure design cohesion by providing a design system and central repository for all design elements.


Working on a design element in a vacuum is a recipe for disaster. Without a living style guide, it can be difficult to visualize how changes to one element flow through to impact others. You may have to scan dozens of product pages to gauge how the updated element plays across all scenarios. Even then, without reviewing every single page, can you be sure something wasn’t overlooked? A living style guide allows you to see the interplay of all elements in a single document.

Streamlining Workflow

If you work in an agile environment, you may have experienced some of the roadblocks that come with working on stories with both frontend and backend needs. Front-end elements – and their designers – are often left in limbo until the backend can be fleshed out. With a living style guide, you’re able to work on front-end components independently. Those design elements can then be seamlessly integrated throughout the product as functionality takes shape.


To work effectively, team members and product owners need to know the resources available to them, and how individual contributions impact others. A living style guide serves as a reference library, allowing team members to review live production elements, contribute ideas and conduct experiments in real time. This makes it easier to talk through potential changes, update comps and get stakeholder input.

mixframe-organization-mini-demoWhile using a living style guide can revolutionize your development workflow today, prototyping new mockups is usually not part of the picture. If your mockups fall out of sync with your style guide, it can create a whole new set of headaches. Try using MixFrame to keep everything consistent. Mixframe enables anyone to build mockups based on the elements in your style guide, giving a team the flexibility to keep design, code and prototypes completely in sync.

As the first prototyping system that evolves with your product, MixFrame makes your living style guide even more valuable. Rather than a disconnected resource library, MixFrame creates collaborative, responsive mock-ups through a simple drag-and-drop interface. Just add a small code snippet to your style guide and the MixFrame attribute to the elements you want to include. Build your pages or templates and share them via MixFrame. Anyone you share them with can then see and review your mockups, or even make changes.

Try the Free MixFrame Demo

Building Rapidly From the Start

As any new startup or product team can tell you, it’s hard to start a new project and not just jump straight to coding features and tools.

Even though the MixFrame team only has a short timeline for building the product, we’ve spent a large amount of time on planning and setup. Sure, we’re coding like crazy; it just hasn’t been the primary focus in our first two weeks.

We’ve already talked about overcoming the uncertainty of starting development on MixFrame, but we also faced the uncertainty of where we’re heading. We knew that a healthy product roadmap for MixFrame was impossible unless we had the knowledge to adjust course intelligently throughout development. So we started building rapidly, without focusing just on getting the product out the door.

Focusing on Viability

As an organization, 352 talks a lot about minimum viable product (MVP), and not just for our clients. Our CEO Geoff has painful, first-hand experience with building a huge product without actually testing it with customers.

Many people wrongly think of MVP as simply the quickest way to introduce a new product to the market. At its heart, however, an MVP’s purpose is to teach you something about your product idea. Eventually, it’ll show you the path to create a product that users crave.

With MixFrame, we don’t want to build a lot of features – we want to build the right features. To reach that goal, we realized a little bit of early foundational work will pay dividends for the lifetime of the product. Mostly importantly, we realized that our product will live and die on data and healthy code.

Marketing played a huge role in winning our Hackathon, and our product growth team has been integral at every step of development. Every story includes measurement, and we’ve baked in lots of analytics and tracking hooks from the start. We’re creating a lean MVP, and this level of data will immediately let us identify which features people love and which are duds.

Focused on All Kinds of Growth

I’ve worked with a few startups and new products that failed to lay the proper groundwork for iteration. An MVP should obviously be a platform for growth, yet too often product teams only focus on feature growth – not customer growth or sales growth.

At some point, we know other 352 developers will step onto the project as we roll back onto client work, and we want to leave a product that’s ready to adapt to customer needs and development best practices. We’ve been steadily unit testing every new line of code to avoid bugs and build a small safety net for future developers. This sets the table for future growth, and it forced us to structure our code in a better, cleaner manner.


We’ve also obsessively built for the right customer. Even though we’re building a product for front-end devs like ourselves, we didn’t want to fall into the trap of building a product only we’d love. Our UX strategist interviewed more than a dozen front-end leaders for feedback and guidance, and we did a company-wide survey to ensure we were using best practices for future development.

It may seem odd to use our short development window to focus on measurement and product health, rather than solely on features. Yet, we’re building rapidly toward a long-term vision. Check back next week to see more progress.

Just Mousin’ Around

When your mouse is over a component in a MixFrame page, a small trash-can button will appear so you can remove the component. Simple, eh?

Mouse interactions are easy to conceptualize and describe. When you put your mouse over X, Y happens. When you move it off of X, Z happens. However, the system powering these interactions is a little more complex.

There are actually two pairs of events you will run into: `mouseover`/`mouseout` and `mouseenter`/`mouseleave`. There a big difference between them that becomes apparent when elements are nested inside each other. See them in action:

mouseover & mouseout

mouseenter & mouseleave

If you use `mouseover`/`mouseout` on nested DOM elements you may get some weird results, because moving your mouse onto a child node will trigger a `mouseout` event, just as if you had moved the mouse completely off the bounding box.

If you use `mouseenter`/`mouseleave` on nested DOM elements, you may get some weird results too. The `mouseleave` event does not fire when you move the mouse onto a child element, even though you might expect it to.

This presented a problem for our little trash-can, causing it to disappear and even flicker at times. Because we wanted to detect (A) when the mouse moved onto a component from anywhere — even a child element — and (B) when the mouse moved out of a component’s bounding box entirely, we needed to use the `mouseover` and `mouseleave` events together. This is a little unexpected, but was exactly what we needed.

UX Iteration: Trash

As you arrange components on your page, you’ll want to remove them from time to time. There are a few ways to do this. We started with the most obvious: a trash-can drop zone in the corner of the screen where you can drag items to be deleted.


This looked neat, and it worked for the most part. However, removing multiple items started to fatigue the eyes and fingers, moving the mouse back and forth across the screen. Larger components also obscured the UI below the ghosted image, making it hard to tell when your mouse was over the trash.

So we’re iterating on this UI, by giving each component a trash can icon instead. As you hover your mouse over each component, an icon-button appears in the corner. Click it, and say bye-bye to that component. This is a much quicker interaction, so it is an improvement over the old drag-and-drop.


Now, the icon-button pops up a lot and it does start to feel somewhat cluttered as is appears and dissappears around the page.

Iterating on this concept, it might be nice to be able to select the component, then delete it. Like you would in a graphics program. This would also work in tandem with more advanced options we have in the roadmap, such as editable text regions.

Currently, this experience is good enough for Phase I. So we’re rolling forward with it, with the plan of iterating down the line!

Building a Digital Product and Overcoming Fear

This week, my team and I kicked off development of a brand new digital project at 352. This is always an exciting time for us, yet this is different. 352 leadership has given us 6 weeks of company time to further develop our own product, Mixframe. Unlike a typical project, I’m a developer, Product Owner, stakeholder and end-user, all rolled into one.

As the product owner, I felt a few opening words to the team were appropriate to show my appreciation, and perhaps to inspire.

steve-ballmer-developersNow, despite being an introvert by nature, some part of me wanted to burst into the room with fanfare. I’d do a lap around the room and scream, “Developers! Developers! Developers!” at the top of my lungs. The team would cheer and high-five. We’d pop a bottle of champagne and dance on the conference room table (or Dougie, or Dab, or whatever kids are doing these days). I wanted to show my excitement.

Yet, flashy displays didn’t feel genuine because there was another feeling I had. Fear.

I’m afraid we won’t chart an effective strategy.

I’m afraid no one will like our product.

I’m afraid we’ll fail.

It’s something I think every Product Owner faces when heading into the unknown world of development, and I knew the team probably had the same fears. And you know what? That’s normal. I think it’s healthy to voice your shared fears and face them together.

So, at Monday morning’s Sprint 0, I left my dancing shoes at home, I kept the champagne corked, and I spoke in an even tone.

And I let the team know that despite all my fears, I’m still excited.


I’m excited because our product is something we’re passionate about. It’s not just a get-rich-quick scheme we’ll lose interest in. It’s a product our team would love to use every day. Not only is this a great reward in itself, it’s also the hallmark of a successful startup. Products are more successful when the team is intrinsically invested in the idea, just like ours.

I’m excited because 352’s executive leadership has shown nothing but support and guidance. New products need an incubation period and time to grow. Our leaders understand that. Every time I’ve spoken with them about our product vision, they have balanced advice. “First, focus on building something you believe in, then put the momentum behind it to let it grow.” It’s inspiring when bosses share your values.

I’m excited for one more reason. I’ve been a loyal employee of 352 for more than 15 years. It’s been an absolute blast but  – just like anyone else – I’ve considered other opportunities from time to time. And I’ve considered forming my own startup. I’ve wondered, if I did such a thing, who would work with me? Where would I find them? Would they be smart enough? Could I trust them? Would my product idea be any good? Would I know how to market it?


So many questions. I’d figure it all out in time but gosh, it would be an agonizing process. Now, I look around the room at my product team – my friends – and I’m blown away. I see some of the smartest and hardest-working people I know, encompassing all the values and skills needed to make a digital product successful. Development to design, from UX to marketing. Where else could someone find such a perfect opportunity?

We’ll be building our product during the next 6 weeks, and we’d like to share our progress with you. We’ll share our stumbles, our accomplishments and show you how 352 builds its products. Hopefully, we’ll show something that excites you.

No one can say what the future holds for our product, but if it can be successful, it surely has the best shot at 352.

And that’s exciting.

UX Iteration: Drawer vs. Modal

Currently, MixFrame keeps your component library in a categorized accordion, nested in a drawer anchored to the right side of the screen. This is great for demoing the project concept because the page and the library are visible in one view.


However, this solution breaks down when you try to do more complex layouts with larger collections of items in your library. As the accordion gets taller it eats away at valuable screen space. Large collections of components can become unwieldy to scroll through, and nested scrollbars start appearing (a UX no-no). As you want to preview the page design, the drawer is always in the way.

So, I’m experimenting with a modal window to house the components instead. In general, I try to avoid modal windows because they are a over-used as an easy solution to a design problem. They force a user into one mode of thinking instead of allowing full freedom. Larry Tesler has even made it his mission to eliminate modes from software design.

But I think if you can quickly open and close the window and it feels fluid with your workflow, it could be an improvement. I’ve attached the Escape key to toggle the window open and closed. With one hand on the mouse and the other on the Escape key, you can jump around and it feels pretty powerful.


I’m putting this prototype in front of my team today and watching how they interact with it. Hopefully it will be an improvement and solve a handful of design issues at the same time.

Building a Winning Hackathon Product

At our annual company retreat last week, 10 teams presented products built during our annual hackathon, the Race to 3:52. From new office and productivity apps, agile tools and DevOps systems, one product emerged victorious: MixFrame.

MixFrame is a first-of-its-kind UI prototyping tool that allows development teams to build responsive mockups using its existing CSS and live style guide or component library. You’ll hear more about MixFrame soon, so we wanted to take a look at the team’s winning hackathon formula.

Screen Shot 2015-08-27 at 3.08.58 PM

Refining Goals

Each hackathon product was judged on a number of factors: marketability, development progress, a product roadmap, user experience, technical execution, design execution and a presentation to judges. Rather than focusing individually on each of these criteria the team simplified its hackathon mission to just three key tasks:

  • Prove the idea is technically feasible.
  • Prove the idea has market-viability.
  • Be able to communicate the above effectively.

From day one, the team avoided anything that didn’t feed into those three goals.

“We only wrote code that would answer the big questions of complexity and reinforce the product demo, and avoided the obvious “in between” bits,” said Lincoln Anderson, MixFrame product owner and front-end developer. “We focused our market research on real people in our market and avoided speculation. We focused on our presentation’s flow and wording, and didn’t worry as much about special effects.”


Screen Shot 2015-08-27 at 11.45.30 AM

For MixFrame, the first task was particularly important. Though industry leaders like Ian Feather and Brad Frost and many others have preached the live-style guide movement for years, there is no existing tool that allows designers and front-end developers to easily leverage the style guide in a production environment.

Since MixFrame held the unique position of introducing a new, complex idea, the team decided that a proof-of-concept was more important than a minimum viable product. They decided that through focus on the features that seemed hard or unsolvable, they’d be able to win over cynics and prove the worth of the product.

“Since this application is pretty complex, finishing the MVP by the end of the hackathon would have been difficult, or impossible. So we strategized on the features that were harder to prove. – Chris Burns, Scrum Master”

After all, any dev worth his or her salt can build a login screen, but what about pulling in external CSS or creating bitmaps of each element – the backbone of the project? So, rather than building a full MVP, the team built a developer preview to show how MixFrame plugs directly into your existing CSS style guide to build responsive mockups using real HTML and components.

Building Connections

From the beginning, the team valued industry outreach and feedback. Since the three-day development timeline made actionable user testing unlikely, the team took deliberate steps to contact industry leaders to gain exposure, validation and traction. The MixFrame team believed in its outreach so strongly that it actually included more marketing personnel than development.

Through the presentation, Lincoln Anderson channeled his inner Elon Musk to connect with hackathon judges with real evidence. He added judge photos to the developer preview (seen above) and highlighted the industry reception from Feather and Tim Wright. Driven by social media outreach, these connections transformed from a simple product idea to one with industry validation and support.

Have a Path to the Future

mixframe-integrationObviously, MixFrame was built with the intent on finishing production and launching to market. Hackathon teams often struggle with the transition from hacking to building – occasionally because they choose a technology stack that lends itself to quick development, rather than intentional development. Ultimately, this leads to a project that must be rewritten for performance, clarity and quality.

Since actual development was limited to proving its concept, the MixFrame team was very intentional in its technology choices to ensure a solid base for future development – unit testing with Jasmine and confirming code standards with editorconfig, jscs and jslint. Most importantly, Browserify allowed the team to easily build the project as if it were normal server-side Node and properly bundle it for the final product build.

Don’t Work to the Last Minute

Though it may seem counter-intuitive for a 3-day hackathon, the team committed themselves to not completely overworking themselves, but spending every minute dedicated to the strategy it thought would win.

“We were honest with ourselves and knew how much progress we could make during the hackathon and leading up to the presentation. We brainstormed as a group and prioritized tasks by impact and likelihood they’d be finished in the initial three days and the 3 weeks before the presentation. Once we were all satisfied, we got to work.”

Just as it simplified its hackathon mission, the team also simplified its workflow. Rather than expanding scope, they focused solely on the ideas that seemed hard or unsolvable and committing to building them without working tirelessly. Of course, even with an intentional approach and a strong strategic vision, winning the hackathon was still a real challenge.

According to Chris Burns, “It was 1 part planning, 1 part effort, 5 parts luck.”