From design to frontend without comps

Our client, Forcepoint, was not only crafting a new identity for themselves, they were reinventing the company through merger and acquisition. A perfect opportunity affording us a clean slate to design and build a new system. Along with the new brand, this project required a responsive, performant UI, and a solution for the internal team to capture changes and additions to the evolving brand system through the life of the company.

Problem: Design from a blank slate to fully functional frontend without traditional comps. What!?!

To top it off, the project had an ambitious, unmovable deadline. Oh yes, and we did this without the expensive overhead of creating Photoshop comps, a tedious workflow that has become insanely monstrous with RWD and in-flux content and/or information architecture. Not to mention our deadline wasn’t kind to creating variants for each mobile breakpoint, and alternatives for the variations in content, and then there’s the accompanying large stakeholder reviews and multiple revisions that come along the way for each mock-up. Could we execute a solution like this? Yes, it’s completely possible to do, because we did it. Let us tell you how.

First off, who are “we”?

Luke Herrington: frontend engineer

Luke comes from the world of single page applications and backend Drupal. With minimal frontend Drupal experience and this being his first project at Four Kitchens, Luke was very interested in what this experience would be like. He was not only tasked with learning best practices, but he also had to implement them. This included Gulp, Singularity, Breakpoint, and Panels. He had his hands full, but it turned out to be a very pragmatic way to lea\r\n \these great tools. Fortunately, a very solid design process set a good foundation for Luke’s work on the frontend.

Jared Rogers: designer

Jared is no stranger to designing for BIG websites, he’s been heavily involved in transitioning Four Kitchen’s design practices away from traditional Photoshop comps towards more modern component based design systems. To ensure success in working with a green Web Chef, he knew he needed to layout a solid process. The process used for designing and implementing this particular Drupal site was not necessarily new, but was a much more refined version of our component-based design system. There are many processes for translating design intention to the buildout, yet the smoothness of this one led to a superior outcome.

Planning

As lead designer, Jared’s primary focus for this project was planning the appropriate patterns and their display, as well as solidifying the content itself.

The new brand

Since the new identity for the newly named company, Forcepoint, was developed by an external agency, Jared and the design team was tasked with choosing how this new brandmark would be conveyed on an interactive model. After regular check-ins with the internal design team and brand agency, we felt we had a strong understanding of the direction, and were able to confidently create assets that carried the new brand to the web.

Interaction design

For planning the interaction design, our design team used Balsamiq wireframes to identify layouts and content, and to highlight necessary functionality for the project team to review. Picking up from our completed wireframes, Jared began to pick apart pieces of information foundational for this website design:

• typography
• color
• grid

And expanded to specific interactions that will be used globally:

• buttons
• navigational menus (for the main menu and search interaction I created a prototype from an existing design found on CodePen)
• form elements
  • checkboxes
  • radio buttons
  • drop-down menus
  • sliders
  • on-off switches / toggles
• tabs
• tooltips
• alerts / messages
• breadcrumbs
• pagination
• icons
• tables

 

Iterating on button design.

Content specific examples (as part of the “Flow”) include, but not limited to, the following:

• grid lists of products
• vertical listing of resources
• featured content cards
• horizontal logo bar
• person teaser grid
• hero image with text overlay
• testimonial tier

 

A testimonial tier.

This list identifies some foundational elements that need to be designed as a part of the whole visual design system. The main tool for planning optional visual treatments was an HTML frontend style guide; this particular framework was developed by fellow Web Chef, Joe Tower. By using this style guide, our team was able to design and demo each of these components from a browser, providing a realistic experience for interactions and a responsive design. It was so successful, in fact, that our design team was able to forgo making static comps entirely. We were also able to extract more useful feedback from the client side, why would our client want a picture when they could pull up the real deal on their device of choice?

Flow

Once the design foundation was set and implemented, and the project got going, the design to frontend process also fell into its own rhythm. Our process was shaped and constrained by the Agile methodology of project management. As described below, the process uses some Agile vocab like “story” and “sprint”—if you’re not familiar with these words, check out this basic overview of Agile at ConsultancyScrum.org:

1. Design a step ahead

Jared blazes the trail by creating components that will be needed in a near future sprint. With Agile, you can often design features that don’t make the cut on the final product; by waiting to create the hi-fidelity versions of these until he was near certain they would be built, we could focus our energy on those sure-things. After these changes are reviewed by team and committed to the style guide repo, it’s time for for our frontend engineer, Luke, to tackle its implementation on the Drupal website.

2. Pull a story

The sprint begins and Luke pulls a story, and then pulls changes in style guide repo.

3. Study the design and strategize a responsive solution (SASS)

Luke studies markup and SASS to understand the intention and the model of the design and maps that to what was built by the back-end developers and where it was positioned according to the wireframe.

Point A (mobile) to Point B (desktop):Luke implements a responsive solution that bridges the gap between Point A and Point B; a Pull Request and markets the ticket as ready for Jared.

4. Build it and code review

5. Review

Jared reviews implementation to ensure the design translated correctly and that its intention was met.

6. Shipit and demo

7. Repeat

As the project matured, frontend velocity increased due to component and code re-usability, and design needs decreased. At this time the flow moved into a simpler phase where Luke was simply composing pre-designed elements and Jared was performing design reviews.

Takeaways

No project is perfect. At Four Kitchens, we’re always improving our processes.

Implement a foundation to increase velocity

On the frontend, the first couple of stories in this project got loaded with some foundational work. An “Implement the Style Guide” story could have helped mitigate this. Using something like the Drupal Style Guide Module helps create a “definition of done” for implementing base styles.

IA / Menu changes

IA changes have deep impacts for the way navigation patterns are constructed, not to mention the impact on a user’s journey, so be weary of stakeholders jumping in requesting a last minute re-org. If you’ve already done the research, you already have a strong defense against untested opinions.

Test multilingual

The nuts and bolts of building a multilingual site with an elegant editorial experience is difficult. Everyone knows that. However, when supporting languages with large differences in word length (think Cantonese compared to German), we learned that planning for those differences can save headaches later. One example is using flexbox to layout menu items rather than floating and adding padding.

• review with client often and early
• code review of frontend work when there’s only one frontend dev is a quandary

Put the Photoshop hours into prototypes

With limited hours and a tight deadline, we could have spent hours on creating variants in Photoshop, instead we limited that to what was necessary and relied on putting the effort into crafting the components within the HTML style guide. At one point, near the launch of the project, our client requested to see the homepage, but we hadn’t finished building it yet. So, rather than build a beautiful version from scratch in Photoshop, Jared made screen-shots of the 3 or 4 frontend components already built in the style guide and pasted them together for the client to see. It worked quickly and easily. Our stakeholders got to preview an image of the site without the overhead of going back and creating comps.

Conclusion

The relationship between designers and frontend developers is very important to the success of a project. Jared and Luke’s process for this particular project worked well, but every site and person is different— your process should be flexible enough to handle those differences. Being dogmatic about processes stunts progress and discourages empowerment. Find something that works for your team and go to it! If it stops working one day, try something new. The important thing is that design and frontend communicate clearly and have a plan for success.

This post was written by Jared Rogers and Luke Herrington.