When designing and developing a website or application, a challenge is that roles and tasks can often operate in silos. While in some cases this is fine, in many others it takes away from the ability to collaborate more closely and ultimately build an even stronger solution. To tackle this challenge, we recently piloted a new component-based design approach that prioritizes real-time collaboration. [Spoiler alert: the results so far are positive!]

At Forum One, we build a lot of sites and applications with Drupal and WordPress, and both content management systems incorporate layout features out of the box. In Drupal 8+, that’s Layout Builder. In WordPress, that’s the Block Editor. These layout tools give content editors the flexibility to build their own page layouts within the CMS’s administrative user interface.  Since component-based design is centered on building reusable elements, this approach fits nicely with these CMS tools: we design and build the elements that our mission-driven organizations can then mix and match in order to suit their needs.  

Last month we launched a new website for Trinity Church Wall Street (TCWS), a historic Episcopal parish in New York City that provides a large array of services and activities to its community. The website redesign project provided a great opportunity for us to pilot a new approach to how our user experience (UX), design, and technology teams collaborate while incorporating component-based design principles.

Component-based design

In the context of website and application development, component-based design means that we focus on building a robust design system of reusable components rather than discrete page layouts. By approaching design modularly, we provide the building blocks that can be combined to build impactful page layouts on the fly. 

Reducing pain points and improving collaboration across teams

Aside from supporting Layout Builder and Block Editor, we had other reasons for reassessing our approach to design and tech collaboration. Our old approach provided fewer opportunities for members of our UX, design, and front-end development teams to work together while focusing on the project goals. We found that the roles were too siloed and there was too much emphasis placed at the page level rather than the more global design system. The teams wanted to focus more on interactive storytelling, and they needed real-time collaboration with each other to do that successfully. 

Another pain point we experienced is that static page design documents don’t always effectively convey intended functionality and interactions. Without tight collaboration, our front-end team could be left to infer how a layout was supposed to behave on different screen resolutions, or what should happen if the content for a dynamic component wasn’t available, or how interactive elements were supposed to work. As a result, initial UX and design visions didn’t always match the end product. Based on this, we felt the right solution was to increase communication between teams and implement a process that focused on getting into code faster. 

What we did on TCWS

After discussing our pain points and goals, our TCWS team piloted an experimental approach. To start, we brought our lead front-end developer into the project much earlier than we normally would, and we established weekly real-time collaboration sessions between UX, design, and front-end development leads. Together, they defined a list of components to create for the site. Each week, the team of three discussed various approaches, sketched various solutions, and experimented with prototypes built in CodePen and Pattern Lab.  

The team had regular sessions with our client team to get feedback on our prototypes, and they also coordinated with the project’s technical lead so that the backend architecture supported what was being prototyped. At first, we reviewed individual components. Over time, we had enough components in our library that we began building prototypes of full pages. After each review session, we documented feedback and decisions and made adjustments in code accordingly. This helped us move more quickly: we didn’t spend time revising static design files because we were able to make the edits right into our front-end code. 

We were also able to demonstrate how the components worked within a browser. Our client was able to use the prototypes to see how elements shifted at different screen sizes, and how interactive elements functioned. This enabled us to get important feedback when it was early enough in the design process to incorporate easily, well before the frontend code was implemented within the CMS templates. 

What we learned

We learned a lot as a result of this pilot project. We learned that creating a library of reusable components requires a lot of planning and detailed documentation to keep everyone on the same page. We learned that collaboration takes time and focus and that our project schedules have to account for it. We learned that prototyping together is valuable because each skill set brings different expertise, which results in a higher quality outcome. We also learned that as content management platforms continue to offer layout building tools, we’ll have less control over every element of each page, and this new approach will allow us to deliver flexible systems that let our clients build beautiful, impactful pages without us. We’re looking forward to using these lessons as we roll out this process to more of our website and application projects.