Rohit Sinha

^{4. Solution}

^{4.1 Information Architecture}

^{I proposed collapsing the product content into three sections, surfaced as a persistent sub-nav directly under the hero section:}

• ^{Overview: introduces product with ‘Try’ option, showcase features and capabilities, provides ‘Explore’ option, cloud integration with Learn more CTA and provide article blogs and Node.js community.}
• ^{Download/Getting Access: precise and clean information using cards showcasing easy, convenient ways to access the Red Hat Node.js platform.}
• ^{Getting Started: provides a in-page navigation technique showcasing all the multiple ways to Start the developer coding journey.}

 ^{This mirrors how developers/architects actually evaluate a product:} 

^{understand → try → get}

^{Rather than a single long-scroll page mixing all three, splitting them lets a returning visitor (who already understands the product) land straight on Download or Getting Started without re-scrolling and therefore “reduces scroll time” goal for repeated visits. This structure also does double duty for the dual-audience goal: a manager or architect doing a quick evaluation typically never leaves Overview – it’s built to answer “is this credible and worth considering” on its own. A developer who’s already interacted using the website moves straight to Getting Started or Download.} 

^{4.2 Above-the-fold hook and CTA}

• ^{One-line product identity (“Red Hat build of Node.js”)}
• ^{One-sentence value proposition, written in outcome language rather than spec language}
• ^{A single primary CTA (“Try now on Developer Sandbox”) paired with a lower-commitment secondary link (“More ways to try”) for users not ready to act immediately}
• ^{A supporting graphic, so the value prop is reinforced visually without adding reading time} 

^{This gives the page a clear hook → proof → action sequence in the first viewport, before any scrolling. Choosing “Try now on Developer Sandbox” as the primary CTA (rather than, say, a “Download” or “Contact sales” action) lowers the commitment required to act — no install, no form.} 

^{That’s a deliberate funnel choice: it turns the hero into a self-service conversion point instead of a lead-gen gate, which matters for a developer audience that tends to disengage from anything that feels like a sales flow.} 

^{4.3 Enterprise grade Visual language}

• ^{Consistent, limited color palette tied to the brand: Red Hat’s signature red is used as an accent against black/white/gray which keeps the page visually calm and puts emphasis on content hierarchy rather than the graphic competing for attention.}
• ^{A consistent icon language: Icons across the portal follow the same outlined, red-accented style seen in this page’s feature tiles, reinforcing that security/trust signals look the same no matter which product a visitor is evaluating.} 
• ^{Use of Cards: We preferred the use of cards, as they aggregate information into a single, easily digestible container. They act as a bridge between diverse content pieces and structured layouts. The cards are highly mobile responsive, provides excellent information scannability, demonstrate clear visual hierarchy to users.}  
• ^{In-page Jump navigation: aka anchor links or skip navigation allows users to click a link and instantly jump to a specific section of the same webpage. This navigation technique lets users interact with content as soon as it appears in view, creating a more engaged reading experience.}  
• ^{Adding multiple CTAs:  Multiple, hierarchically structured CTAs, added wherever relevant, reduce interaction friction and support users at different stages of decision-making by reducing interaction friction and catering to diverse user mindsets across different stages of decision-making.​​​​​​​}
• ^{Illustration/Graphics usage: the graphics work as a small, disciplined set rather than a scattered collection of one-off visuals. Color is used just as tightly: rather than a different color per feature (a common SaaS pattern that quickly turns busy), the icon set stays within Red Hat’s core red-black- white – gray system, using red purely as an accent on otherwise flat, outlined shapes – which keeps six back-to-back tiles feeling like one unified set instead of six unrelated illustrations competing for attention.}

^{4.4 Feature proof section:} 

^{Below the fold, six feature tiles (Supported, Familiar workflow, Shared components, Flexible, Secure, Containers) each pair a small icon-style graphic with 2–3 sentences. This format was chosen to keep enterprise credibility signals (security, support, compliance/FIPS) scannable rather than buried in paragraphs — supporting the scroll-time goal even in the parts of the page that couldn’t be fully eliminated.}

^{5. The Outcomes}

_{^{Measured via Red Hat Developer Portal analytics, comparing 30-day pre/post-launch scroll depth and CTA click time}}

•  ^{The Newly designed RedHat build of Node.js reduces the time to CTA by 42% and un-necessary scroll depth by 65%. Visitors reach the CTA in one screen instead of three.} 
• ^{The Overview, Getting Started and Download page structure I proposed is now the standard pattern across other Red Hat product pages and Topic pages.}
• ^{The proposed IA and hero direction were approved by the product and content teams with minimal revision, and the page has remained live and unchanged in structure since launch.} 
• ^{In retrospect, the page succeeds on the fundamentals it set out to solve: it communicates Node.js’s value clearly to a global audience, keeps the UI clean, and uses restraint — surfacing only what’s relevant rather than overselling the product. The graphics, icons, and CTA placement were built to support that restraint, not compete with it.}

^{6. Key Takeaways}

^{Working within Red Hat’s existing design system meant a different kind of discipline than designing from scratch: every decision had to feel native to the portal, not just good on its own. If I revisited this project, .the one thing I’d prioritize is the sessions, discussions, and interviews that took place before launch. The design was shaped by stakeholder feedback. I was a part of multiple discussions, that slowly shaped the Red Hat Node.js page where it is today. Multiple sessions were focused on trimming irrelevant content, placing CTAs at the right points in the page, and catching the smaller details that could otherwise dilute the page’s impact.}  

^{At the project’s beginning, my approach was to simply shorten the content, but the bigger win came from splitting the page into Overview, Getting Started, and Download — letting different visitors (a first-time evaluator vs. someone ready to download) reach what they needed without scrolling past content meant for someone else.}

^{High fidelity Mockup + New Red Hat Node.js website}