My experience using PatternFly for a website revamp
PatternFly is great for app design and development, but I’ve used it for something sort of unique: a website revamp. As a member of Red Hat’s Developer Program team, I’ve had a fun ride with the Developers site redesign. I was part of the process every step of the way — and so was PatternFly. Here’s my story.
Why PatternFly?
You’re probably wondering why we went with PatternFly, right? First, some context: The Red Hat Developer Program exists to help enterprise developers gain new skills along their career journey. The goal of the website is to create a place where learning and community can thrive for current and future members. We were looking to increase engagement and content density on the site.
When we decided on PatternFly, we still had some hesitations. We weren’t sure if PatternFly would work for websites since it is commonly used for applications. But one of the developers put it right into use by recreating the home page, and boom! It worked.
The process
Migrating the site over to use PatternFly came with some hardships, but overall, it was a pretty seamless process. We had a few variables that were not in our favor, including time and the size of our team. With those aside, we were able to hit our deadline with the best work we could get out, and we were able to make note of the areas we needed to improve on within the following sprints.
The process itself went something like this:
Step 1: Verify we can use PatternFly on the site
First, the development team used PatternFly to recreate the home page. They swapped out the existing infrastructure being used and replaced it with PatternFly, attempting to recreate all items on the page with existing PatternFly variables. This gave us an idea of what was possible and what we may need to customize to support developer-specific components.
While they were working on that, the design team was thinking about the experience on the site and how it will be impacted by adding PatternFly. Every website has visitors, which is the audience that usually comes to mind when thinking about the target user group. But we also have to support our content creators’ experience, which includes the users creating content on the site within the CMS. The CMS we use for the Developer Program is Drupal. So, we were not only evaluating how PatternFly would render on the front end, but we also had to analyze how it would impact the nodes, assemblies, and content creation process as a whole.
Here were some of our outcomes from this step:
Development outcomes
As part of the Proof of Concept, the developers looked into what it would take to integrate PatternFly Core into the build process.
“Integration was made easy by the distributed SCSS files that are part of the NPM package.”
— Adam Joliceour, Senior Interaction Designer at Red Hat
After this step, they started testing out various components with the new styles, which included primary elements on the home page like the layout, cards, and buttons.
Design outcomes
All content types could be recreated using PatternFly’s flexible and modular components (with some customization needed to support the specific data we wanted to highlight). PatternFly will increase the amount of customization and flexibility content creators have while creating sections of the page since they can use the grid layout and components to create whatever content and layout they want.
Step 2: Create a developer site design system that uses PatternFly at its core
The design team worked on designing a pattern library that would be used as building blocks to create full pages. There were parts of the system, like the typography, that came with a simpler solution since it was already determined in the universal Red Hat web design system. It was easy to customize PatternFly’s typography styles to match those of the web.
Then, we tried to leverage what we could from PatternFly’s variable system, like the spacing system, the background colors, the text colors, the button sizes, and the layouts. After, we concentrated on what we needed to customize from the system, which included CTA types and colors, cards (including the spacing, labels, and borders), and some additional typography styles and icons. We used a similar naming system as PatternFly to create the customized Red Hat Developer variables.
There was a lot of collaboration between developers and designers at this point since we were getting the variable system set in stone. The developers continued building on the last stage by adding a front-end documentation demo website. Full implementations were added to this site as designs came in to support. It was more efficient to start from the smallest building blocks, as it was for design. So much of the work was completed in a similar way.
Here were some of the outcomes:
Development outcomes
A huge outcome of this step was the front-end documentation site that documented full implementations of the new designs. Pages were also recreated on this site, for example, the home page redesign.
“This demonstration allowed us to hand off the updated styles and layouts to the Drupal team, who then proceeded to create the Assemblies and Components necessary for content creators to use on the site.”
— Adam Joliceour, Senior Interaction Designer at Red Hat
Design outcomes
A full symbol library was created in Sketch to make designing on the team with the new system more efficient. From that library, we recreated site pages using the new styles and layouts that were now available. Many of the designs that came out of this step were for specification purposes and were handed off to developers quickly. We also collaborated with the developers to come up with a working variable system.
Step 3: Rebuild the site
At this point, we were pretty crunched for time, so the developers deserve a considerable amount of credit for how fast they worked. Stories were made to track all of the work that needed to be done for the first release. A front-end developer would start working on them to ensure the CSS/HTML was correct.
Designers then came into the mix to help review PRs for these new components. Once the PR was approved, Drupal developers took the story on and referenced the front-end code in order to get the components working within assemblies, ultimately enabling content creators to use them. More reviews would take place after this was done to check that all requirements were satisfied. Once that was approved, the PR got merged into a staging site, and everyone on the team was able to see how the site would look and work.
Designers and developers were constantly collaborating during this step, passing specs back and forth and gathering feedback to keep moving. Reviewing the PRs at this point was extremely important. We needed to make sure that all the requirements that were satisfied by the site before the redesign were still being satisfied with the new site. And most importantly, we also had to ensure that it solved our original problem. Each new component, assembly, or page would ultimately allow us to increase content density on the page and increase engagement.
We ended up releasing what we had at that point and, since then, we have been building on it.
The end result
We found that PatternFly was a great solution for our website. There may have been components that we needed to customize, but it gave us the amount of flexibility we were searching for.
We still have some more work to do on the site and will constantly be adding new assemblies and pages. But PatternFly put us many stages ahead of where we were.
If you’d like to share some of your own UX knowledge, please get in touch. We’d love to feature an article by you on PatternFly’s Medium publication.
