From Concept to System
When I joined the BRPA project team, visual design was already in progress. Steph Loughran, the project’s original designer, was leaving NewCity and I would be taking over. The client team had chosen a design direction based on one of Steph’s element collages, so I had a great foundation to work with.
BRPA Collage by Steph Loughran — shown for reference.
Instead of diving into page layouts, I started by creating individual design system components atomically based on the direction shown in the collage. Then I designed page mockups using those atomic design components.
Gallery: BRPA Atomic Components
Click images to embiggen — use the zoom tool in the top right of the lightbox viewer if you want to read all the boring wonderful details or click here to download a full-resolution version.
Designing for Development
Despite my long history as a design/dev hybrid, this was my first experience designing something that would be entirely coded by someone else. In all my previous work, if I did the visual design, I did the coding as well.
Most of my development experience, however, was in coding designs created by designers who were not me. During the BRPA design phase, I tried to draw from that experience and create design mockups that were developer-focused and addressed issues I often experienced as a front end developer interpreting design work.
One of the ways I did this was to prioritize showing variants of patterns that I normally have to infer or invent as a developer: color schemes, active states, verbose content, etc. While designing, I made a prototype instance of Pattern Lab to test some of my ideas and ensure they could be built easily before showing them to the client.
Gallery: Global Navigation Patterns
These mockups showed how the site’s global navigation would behave on large and small screens. The in-context examples show how the navigation would behave on an actual page, instead of in the vacuum of an empty artboard.
Click thumbnails to view in lightbox. Compression obscures some of the small color details; click here to download a zip of higher-quality examples.
Gallery: Section/Sidebar Navigation Patterns
These mockups demonstrate the behavior of the secondary or sidebar navigation for large and small screens. On small screens, the section nav is collapsed by default and the user can click to expand it.
Click thumbnails to view in lightbox.
Page Designs
These selected page designs show the atomic patterns in action. Since they’re designed using a library of predefined components, the pages stay consistent and modular.
Click images to view in a lightbox. To see the whole set at full resolution, download this zip file.
Working with Third-Party Tools: Tripadvisor and Time.ly
For both the parkway and BRPA’s member organizations — mostly tourist attractions, hotels, and restaurants — Tripadvisor is critical. To leverage online booking and showcase the excellent ratings of the parkway and its member organizations, we needed to integrate Tripadvisor data into the site. To achieve this, we had to work with Tripadvisor’s API, within their visual design guidelines, plus get the designs approved by Tripadvisor before development could begin.
Due to my development experience, it was easy to review the API documentation and create designs based on what was possible within their framework.
Gallery: Tripadvisor Mockups
In order to use data from Tripadvisor, the Tripadvisor logo had to be prominent and “as close to the data as possible.” I made these mockups to be approved by Tripadvisor and also for the developer’s reference.
Click images to view in a lightbox. To see the whole set at full resolution, download this zip file.
Theming Time.ly
Another third-party tool the BRPA site made heavy use of was Time.ly, an event calendar tool the client was already using on their old site. The new site needed to use the existing calendar data, reskinned to match the new look.
Because of my front end background, it was easy for me to provide specific feedback to the project’s developers. Once the Time.ly integration was running, I made design changes in the browser inspector then reported those changes to the development team.
This sounds like a backwards approach, but it had a lot of advantages. It saved design time — I didn’t waste time drawing event feeds in Sketch that then couldn’t be applied due to how the markup and API functioned. It also saved the developers from having to review a mockup and reverse-engineer what actually needed to be changed.
