Frequently Asked Questions

Website Rewrite & Design System

Why did Hygraph decide to rewrite its marketing website?

Hygraph chose to rewrite its marketing website to address issues such as codebase complexity, design inconsistencies, and inefficient collaboration between designers, developers, and content editors. The rewrite aimed to establish a scalable, flexible, and brand-consistent platform that could easily adapt to future changes. For more details, see the blog post (Sep 09, 2024).

What were the main challenges with the previous website?

The previous website suffered from a large, unwieldy codebase, lack of reusable design elements, slow review processes, and inconsistencies in visual identity. Collaboration between teams was inefficient, and there was no single source of truth for design standards. These challenges made it difficult to maintain and scale the website effectively. Source: Hygraph Blog.

How does the new design system improve collaboration?

The new design system centralizes reusable components and design standards, allowing designers, developers, and content editors to work more efficiently. Stakeholders can reference available components in Storybook, reducing back-and-forth and enabling faster page creation. This approach streamlines the workflow and ensures consistency across the website. Source: Hygraph Blog.

What are the benefits of having a design system for the website?

Benefits include faster page creation, easier updates across multiple pages, improved brand consistency, reduced dependency on designers and developers for every new page, and enhanced accessibility. The design system also future-proofs the website, making it adaptable to brand or visual changes. Source: Hygraph Blog.

What drawbacks or challenges did Hygraph face during the website rewrite?

The rewrite required significant upfront investment and sometimes imposed constraints due to predefined components. However, the design system is considered an evolving asset, and the efficiency gains outweigh the initial challenges. Source: Hygraph Blog.

Features & Capabilities

What are the key features of Hygraph?

Hygraph offers a GraphQL-native architecture, content federation, scalability, and a user-friendly interface. It supports integrations with platforms like Netlify, Vercel, Shopify, BigCommerce, AWS S3, Cloudinary, and more. Security features include SOC 2 Type 2, ISO 27001, and GDPR compliance. For a full list, visit the Hygraph Features page.

Does Hygraph provide an API?

Yes, Hygraph provides a powerful GraphQL API for efficient content management and delivery. Learn more at the Hygraph API Reference.

What integrations does Hygraph support?

Hygraph supports integrations with hosting and deployment platforms (Netlify, Vercel), eCommerce solutions (Shopify, BigCommerce, commercetools), localization tools (Lokalise, Crowdin, EasyTranslate, Smartling), digital asset management (Aprimo, AWS S3, Bynder, Cloudinary, Mux, Scaleflex Filerobot), personalization and AB testing (Ninetailed), AI (AltText.ai), and more. For details, visit the Hygraph Integrations page.

How does Hygraph ensure security and compliance?

Hygraph is SOC 2 Type 2 compliant, ISO 27001 certified, and GDPR compliant. It offers SSO integrations, audit logs, encryption at rest and in transit, and sandbox environments to protect sensitive data and meet regulatory standards. More information is available on the Hygraph Security Features page.

Pricing & Plans

What is Hygraph's pricing model?

Hygraph offers a free forever Hobby plan, a Growth plan starting at $199/month, and custom Enterprise plans. For full details, visit the Hygraph Pricing page.

Use Cases & Benefits

Who can benefit from using Hygraph?

Hygraph is ideal for developers, IT decision-makers, content creators, project/program managers, agencies, solution partners, and technology partners. It serves modern software companies, enterprises seeking to modernize, and brands aiming to scale, improve development velocity, or re-platform from legacy solutions. Source: ICPVersion2_Hailey.pdf.

What business impact can customers expect from Hygraph?

Customers can expect time savings, streamlined workflows, faster speed-to-market, and enhanced customer experience through consistent and scalable content delivery. These benefits help businesses modernize their tech stack and achieve operational efficiency. Source: ICPVersion2_Hailey.pdf.

What problems does Hygraph solve?

Hygraph addresses operational pains (developer reliance, legacy tech stacks, global team conflicts, clunky content creation), financial pains (high costs, slow speed-to-market, expensive maintenance, scalability challenges), and technical pains (boilerplate code, overwhelming queries, evolving schemas, cache and OpenID integration issues). For more details, visit the product page.

Can you share specific customer success stories?

Yes. Komax achieved 3X faster time to market, Autoweb saw a 20% increase in website monetization, Samsung improved customer engagement with a scalable platform, and Dr. Oetker enhanced their digital experience using MACH architecture. More stories are available on the Hygraph Case Studies page.

What industries are represented in Hygraph's case studies?

Industries include food and beverage, consumer electronics, automotive, healthcare, travel and hospitality, media and publishing, eCommerce, SaaS, marketplace, education technology, and wellness and fitness. See Hygraph Case Studies for details.

Technical Requirements & Documentation

Where can I find technical documentation for Hygraph?

Comprehensive technical documentation is available at Hygraph Documentation, covering setup, integrations, API usage, and more.

How easy is it to get started with Hygraph?

Hygraph is designed for quick onboarding. Users can sign up for a free account and access documentation, video tutorials, and onboarding guides. For example, Top Villas launched a new project in just 2 months. Learn more at Hygraph Documentation.

Support & Implementation

What support does Hygraph offer after purchase?

Hygraph provides 24/7 support via chat, email, and phone. Enterprise customers receive dedicated onboarding and expert guidance. All users have access to documentation, video tutorials, and a community Slack channel. More details at the Hygraph Contact Page.

What training and onboarding resources are available?

Hygraph offers onboarding sessions for enterprise customers, training resources such as video tutorials, documentation, webinars, and access to Customer Success Managers for expert guidance. Source: Hygraph Contact Page.

Customer Proof & Testimonials

Who are some of Hygraph's customers?

Notable customers include Sennheiser, Holidaycheck, Ancestry, Samsung, Dr. Oetker, Epic Games, Bandai Namco, Gamescom, Leo Vegas, and Clayton Homes. For more, visit Hygraph Case Studies.

Performance & Metrics

How does Hygraph optimize content delivery performance?

Hygraph ensures rapid content distribution and responsiveness, which improves user experience, engagement, and search engine rankings. Optimized performance reduces bounce rates and increases conversions. More details at this page.

What KPIs and metrics are associated with Hygraph's solutions?

KPIs include time saved on content updates, system uptime, consistency across regions, user satisfaction scores, reduction in operational costs, time to market, maintenance costs, scalability metrics, and performance during peak usage. For more, see the Hygraph blog on CMS KPIs.

Webinar Event: How to Avoid Personalization Tech Traps

How Hygraph uses Hygraph I: Why a rewrite

Why we rebuilt our marketing website from the ground up.
Dino Kukic

Written by Dino 

Sep 09, 2024
Mobile image

Every now and then there comes a new developer in the marketing team, who looks at the codebase and thinks to himself “Hey, instead of figuring out this monster, why don’t we re-write the thing in {insert_new_trending_JS_framework}”. And that’s exactly what we did.

However, it didn’t exactly happen that way. At some point last year, we realized that following the rebrand from GraphCMS to Hygraph, we had a lot of pages that had survived multiple cosmetic changes and have reached a point where it really made sense to make something new, funky, fresh, and scalable (and, yeah, perhaps also consistent).

Joking obviously on the JS framework part, we love them all, but we were quite happy with the tech stack we had: Next.js on the frontend, Hygraph on the backend, and a couple of other things in between that I’d let other, more skilled people talk about in the next parts of this article. So on the tooling side, it didn’t change much and we were lucky to have it happen at the time when Next.js 13 came out so we could also incorporate App Router right from the start. But more on that later.

Having said that, this article is part 1 of the 5-part saga on this journey and I aim to give you a glimpse into our website rebuilding project: what did we do, why didn’t we make the changes incrementally, why this may be the way to go sometimes, and, well, what are the drawbacks if you decide to take inspiration from us.

#What did we do and why not incrementally?

Given the issues I have briefly mentioned, when we were deciding what to do with the website, we came to the conclusion that we might require a design system. There are a few ways of thinking about this.

On one hand, our website is rather small with less than 1000 pages and you can reduce that to a certain number of templates that just keep getting reused. So why build a full-fledged design system for a website of that size? We might want to be flexible and keep changing things and when we need a new page that has a whole new set of requirements we can just build it from scratch without the constraints of a design system.

However, that kind of thinking led us to this path and precisely because we do change things quite often we wanted to have a centralized system where those things can be changed. And, there were other issues.

No link between the designers and developers

The way we worked prior to making this change involved very few reusable elements. New page designs were almost entirely from scratch, as was the implementation. This meant that the review process was taking too long and was rather inefficient.

The codebase was too big

You could almost predict this point reading the previous one. As we built the new pages almost from scratch, the codebase was getting out of hand. Some GraphQL queries were in the .tsx file for the page, some were in a separate folder, some content was in the CMS, some of it was hardcoded and I can go on, but you get the idea.

Inconsistency across pages

Throughout the years, we have changed a few things here and there regarding our visual identity, some smaller, some bigger, and it was getting harder and harder to make the required changes on the website as well. This led to many inconsistencies across different pages in terms of color schemes and other design details.

Improve collaboration between designers, developers, and content editors

If you think about the lifecycle of a certain landing page, our old way of doing things, would make it so that the stakeholder or person in charge of delivering a page, for example a PMM, would start with a rough mockup and content and pass it on to the designer who would then pass it on to the developer.

Oftentimes, this would cause the back and forth regarding what’s possible and what not between the three. The new way is that, in this instance PMM, can refer to the design system in Storybook to see which components and variations are available and construct a mockup and content around that or request a new addition in order to achieve what’s required.

Lack of single source of truth to refer to

This is probably one of the items that ChatGPT would offer us as one of the reasons to have the design system to begin with. Having it in place means we have no more doubts about the color codes, shadows and more.

Build pages more quickly

At the end, most likely one of the most important reasons to undertake this project is to become a bit more agile and built new pages more quickly and efficiently. When I mentioned the new page creation process before, here’s how that looks like now. We’ve got two types of pages:

  • Templatized pages: page templates that require only content input in the CMS and will be rendered accordingly. Most obvious one is the one you’re reading this article on, but similarly the individual resource pages, events pages and alike.
  • Modular pages: these take different inputs and a content editor can use nearly all available components to create a page. With this the content editor has a lot of flexibility, to choose the layout of certain sections, include an image, video or codeblock and a lot more. Here’s a quick overview of how would that look like for a hero section:

Internal image_ Part zero.png

Accessibility

At the end, accessibility was also not something that we paid a lot of attention to in the past and at this stage we wanted to address it properly. So having a design system in place would allow us to work with a color scheme that is accessible. On the keyboard side we still have some work to do, but we did make a big first step.

#Again, why not incrementally?

Now, given the nature of the project, it was effectively a rewrite and the only way we could do it incrementally, was to serve parts of the website from the new repo as we progress. And, we categorically agree that all migrations should be incremental. So, we did come across the possibility of using the rewrites in Next.js, however, we (read: I) were skeptical for a few reasons:

  • Setting up rewrites and reverse-proxy would cause a certain delay and possibly affect our page load speed. Now you may say, if properly done it’s insignificant and you may be right, but we didn’t want to risk it as our organic traffic was on a roll
  • In addition, going through that process and making sure everything was correctly set up (only pages on hygraph.com are indexable in search engines, and similar) seemed not worth it, considering the effort vs. benefit given the size of the website. (Famous last words incoming) It was also highly unlikely we’d introduce something that would cause a major disruption in the world.

I have touched upon what we consider as the benefits we reap from successfully completing this project, but I’ll go over those now in more detail.

Future-proofing the marketing website

We wouldn’t go this route if we weren’t sure that this will set us up for success for a long period of time. The whole idea around it was to build something scalable that is also flexible enough to be agnostic to any kind of brand or visual changes in the future. At the same time, regardless of what type of pages we want to put out there, we can always add new components and new component variations.

Easier to change the templatized pages

This one is also an obvious one: say we want to update one component on a page that’s used across 300 pages such as blog articles; that’s something we can do rather easily and in one file that will reflect all of those 300 pages.

Easier to make bigger changes

I have touched upon this topic a few times previously but it deserves special attention, because we did go through a rebranding process and it required quite a bit of work to get things updated. Nowadays those can be updated in one central place and we are good to go.

Reduces dependency on horizontal resources

I have mentioned the way we build the modular pages and this means that there’s quite a lot we can do with the existing components. Meaning not every page will require a designer and developer in order to make it happen.

Brand consistency

At the end, this also helps us keep our brand consistent across the website.

#Is it all milk and honey?

Of course, it’s not. This kind of project requires a significant upfront investment. And you may argue whether for a website of our size it’s worth it or not, but we are doing things a lot more efficiently nowadays so it’s just a matter of choosing the right moment to do it.

Now I am not big on high-level graphs and quadrants, but if we wanted to make a scalability/investment and a time/investment graph on the design system vs. not having one, it may look something like this:

Internal image_ Part one.png

The other thing is that sometimes having to choose from a pre-defined set of components may seem like a significant constraint, but it’s doable and we consider our design system as something that’s constantly evolving.

That said, head over to the next part and find out how our design system is set up.

Blog Author

Dino Kukic

Dino Kukic

Head of Demand Generation

Share with others

Sign up for our newsletter!

Be the first to know about releases and industry news and insights.