Lean Website

A full redesign and rebuild of Lean's corporate website, created to improve its visual quality, update its content, simplify maintenance, and turn the website into a product that could keep evolving.

Context

Lean needed a website that reflected the scale and direction of the company.

The previous website had become difficult to maintain. It was based on a Webflow export and behaved more like a static collection of pages than a managed digital product. Updating content could require development effort, the structure was difficult to extend, and the visual experience no longer represented the quality or ambition of Lean's work.

The website also had to serve several audiences:

• Government and healthcare stakeholders.
• Potential partners.
• Existing clients.
• Job candidates.
• Researchers and industry professionals.
• Media and communications teams.
• People who wanted to understand Lean's role in the Saudi healthcare ecosystem.

The work started as a redesign, but it grew into a much broader product and engineering effort.

I became responsible for leading the project, designing the experience, coordinating with internal teams, supporting content development, shaping the technical direction, implementing the front end, and helping move the website through launch and continued improvement.

Later, I took wider ownership of the website as an active product. That included CMS enhancements, new pages, responsive QA, content updates, performance work, SEO, GEO, search visibility, and new visual directions.

Problem

The project had several connected problems.

1. The website did not reflect Lean's current position

Lean works across national health platforms, data, infrastructure, AI, and health and life sciences. The website needed to communicate this without becoming dense or confusing.

The previous visual and content structure did not fully express:

• The scale of Lean's work.
• The relationship between its products and services.
• Its role in the healthcare ecosystem.
• Its innovation in data, AI, and health technology.
• Its value to partners, clients, and the public.

2. Content changes were slow

The previous architecture made updates harder than they needed to be.

Small and medium changes could take weeks because content and layout were closely tied to development. The communications and digital experience teams needed more control over routine updates without rebuilding or manually editing static pages.

3. The site needed a clearer information architecture

Lean has several products, services, reports, partnerships, news items, and areas of expertise. The website needed a structure that could grow without turning the navigation into a long list.

The information architecture had to help users answer:

• What does Lean do?
• Which products does Lean operate?
• What solutions does Lean provide?
• How does Lean contribute to healthcare?
• How can an organization work with Lean?
• Where can I find reports, research, and news?
• How can I join the company?

4. The experience needed to work in English and Arabic

The site needed more than translated text.

Arabic introduced requirements around:

• Right-to-left layout.
• Content length.
• Typography.
• Image direction.
• Navigation behavior.
• Form layout.
• Component mirroring.
• Responsive behavior.
• Quality assurance across both languages.

5. The visual direction needed to feel modern without losing trust

The website needed to feel:

• Modern.
• Premium.
• Clear.
• Calm.
• Health-focused.
• Enterprise-ready.
• Technically advanced.

The challenge was to create a richer visual identity without making the site feel decorative, trendy, or difficult to use.

6. The project crossed several teams

The website required input from design, content, marketing, communications, business teams, leadership, development, infrastructure, and external services.

This created risks around:

• Unclear ownership.
• Delayed content.
• Conflicting feedback.
• Technical dependencies.
• Launch readiness.
• DNS and Cloudflare tasks outside my access.
• Search indexing and reindexing delays.
• CMS configuration.
• Page-by-page quality control.

7. The website needed to remain useful after launch

A redesign can look successful on launch day and become outdated soon after.

The site needed:

• Reusable components.
• A clear content model.
• A maintainable codebase.
• A CMS.
• Defined ownership.
• A process for new pages and updates.
• SEO and discovery improvements.
• Continued measurement and iteration.

My Role

I worked across product design, front-end engineering, content, coordination, quality assurance, and product ownership.

Project leadership

I led the project and helped keep the work moving across teams.

I:

• Defined the design and delivery direction.
• Broke the work into phases.
• Coordinated with internal teams for content and requirements.
• Tracked dependencies and open decisions.
• Helped teams reach agreement on page structure and priorities.
• Managed design and implementation work against launch needs.
• Supported quality assurance and release preparation.
• Continued ownership after launch.

UX and information architecture

I helped structure the website around the questions users needed answered.

My work included:

• Auditing the existing website.
• Reviewing page structure and content gaps.
• Organizing products, solutions, reports, news, and company information.
• Designing page hierarchies.
• Creating navigation and cross-linking patterns.
• Improving user journeys to key actions.
• Designing responsive page structures.
• Supporting Arabic and English experiences.

UI and visual direction

I designed a new visual language for the site.

The direction used:

• Clear hierarchy.
• Strong whitespace.
• Calm healthcare-inspired presentation.
• Premium but controlled use of glass effects.
• Modern cards and layered sections.
• Large editorial typography.
• Visual storytelling rather than repetitive corporate blocks.
• Responsive motion where it added meaning.
• Reusable patterns rather than one-off pages.

Front-end engineering

I did not stop at design handoff. I worked on the actual implementation and took ownership of the website as a production product.

The technical direction included:

• Next.js App Router.
• React.
• TypeScript.
• Tailwind CSS.
• shadcn/ui.
• Radix UI primitives.
• Payload CMS.
• Vercel deployment.
• Reusable page and content components.
• Responsive layouts.
• Arabic and English routing.
• CMS-driven content.
• Front-end QA and iteration.

Content and CMS work

I supported the shift from static pages to a maintainable content system.

This included:

• Helping define page types.
• Structuring content fields.
• Supporting bilingual content.
• Building reusable modules.
• Creating patterns for reports, news, products, solutions, and forms.
• Making routine content changes easier.
• Supporting later CMS enhancements.

SEO, GEO, and discovery

After the main release, I expanded the work into search and AI discovery.

I reviewed and improved areas such as:

• Metadata.
• Heading structure.
• Internal links.
• Image names and alternative text.
• Report naming.
• Robots.txt.
• Sitemaps.
• Structured data.
• Indexing.
• Search reindexing.
• Client-side content that search engines could miss.
• Performance and page quality.
• Content clarity for traditional search and AI systems.
• Infrastructure items that required Cloudflare or administrator support.

Ongoing product ownership

I continued to treat the website as a living product.

I worked on:

• New pages.
• CMS updates.
• Arabic QA.
• Responsive refinements.
• Landing-page improvements.
• SEO and GEO.
• Reports and news.
• Visual experiments.
• Technical fixes.
• Content quality.
• Release planning.
• Handover and process improvement.

Approach

1. Audit the existing experience

I started by understanding what the current website did well and where it created friction.

The audit covered:

• Page structure.
• Navigation.
• Content clarity.
• Visual hierarchy.
• Responsiveness.
• Reusability.
• Update process.
• Technical architecture.
• Search visibility.
• Arabic support.
• Missing pages and information.

This made the project more than a visual refresh. It created a list of product, content, and technical problems to solve.

2. Define the website as a product

I treated the website as a platform with users, owners, workflows, and a roadmap.

The main principles were:

• Make Lean understandable.
• Make key information easy to find.
• Create a visual experience that matches the company.
• Make updates faster.
• Support English and Arabic equally.
• Build reusable components.
• Give content owners more control.
• Keep the site ready for future growth.

3. Restructure the information architecture

I organized the site around a clearer set of user needs.

The architecture included areas such as:

• About Lean.
• Products.
• Solutions.
• Health and Life Sciences.
• Partnership.
• Reports and research.
• News.
• Careers.
• Contact.

I also worked on how these areas connected, so users could move from a high-level story into deeper product, solution, or research content.

4. Establish the visual system

I created a visual direction that balanced innovation with trust.

The system included:

• Type scale and hierarchy.
• Spacing rules.
• Responsive grids.
• Card patterns.
• Navigation.
• Buttons and calls to action.
• Forms.
• Content blocks.
• Report and news layouts.
• Image treatments.
• Glass and depth effects.
• Motion guidelines.
• Arabic behavior.
• Mobile states.

The goal was not to make every section look different. The goal was to create enough flexibility for storytelling while keeping the site consistent.

5. Build a reusable component architecture

I translated the design system into reusable front-end components.

This reduced duplication and made new pages faster to build.

Examples included:

• Hero sections.
• Content grids.
• Product cards.
• Report cards.
• News cards.
• Timeline sections.
• Statistics.
• Forms.
• Calls to action.
• Navigation.
• Footer.
• Bilingual content containers.
• Rich text.
• Image and media blocks.

6. Deliver in phases

The project used a phased release approach.

A practical sequence was:

1. Build and validate the English experience.
2. Add and test Arabic.
3. Integrate and improve CMS support.
4. Complete broader QA.
5. Launch.
6. Continue with SEO, GEO, content, and visual improvements.

This reduced the risk of trying to solve every problem at once.

7. Coordinate content and implementation

A corporate website depends on content as much as design.

I worked with teams to:

• Collect page requirements.
• Review copy.
• Organize English and Arabic content.
• Confirm product and service information.
• Prepare report pages.
• Add news and partnerships.
• Resolve missing content.
• Match content length to layout.
• Keep implementation moving while some content was still being prepared.

8. Test across devices and languages

I reviewed the site across:

• Desktop.
• Tablet.
• Mobile.
• English.
• Arabic.
• Different content lengths.
• Forms and interaction states.
• Browsers and responsive breakpoints.

The Arabic experience required its own review rather than a simple mirrored layout.

9. Improve search and discovery after launch

I treated launch as the beginning of the next phase.

I reviewed audit results and worked through issues related to:

• Metadata.
• Content structure.
• Broken or weak links.
• Technical SEO.
• AI visibility.
• Performance.
• Index coverage.
• Client-rendered data.
• Infrastructure dependencies.

I separated items I could fix in the application from items that needed support from infrastructure or Cloudflare administrators.

10. Explore richer digital storytelling

The website also became a place to explore more advanced ways to explain Lean's work.

I developed or supported concepts such as:

• Layered views of infrastructure, data, health intelligence, and health services.
• 3D Saudi map concepts.
• Scroll-led product narratives.
• Interactive visual systems.
• A "Layers of Intelligence" concept.
• More visual, less conventional landing-page sections.

Some of these remained explorations rather than shipped features. They helped define possible future directions for the site.

What I Built

A new responsive corporate website

I designed and implemented a new site that improved both presentation and maintainability.

The work included:

• A redesigned home page.
• Updated company story.
• Product and solution pages.
• Health and Life Sciences content.
• Partnership journeys.
• Reports and research pages.
• News.
• Careers.
• Contact.
• English and Arabic experiences.
• Responsive navigation.
• Forms.
• Calls to action.
• Reusable content modules.

A maintainable front-end system

I built a component-driven architecture using Next.js, TypeScript, Tailwind CSS, shadcn/ui, and Radix UI.

This created:

• Reusable components.
• More consistent implementation.
• Faster iteration.
• Better responsive behavior.
• A clearer path for new pages.
• Less dependence on manual static editing.

CMS foundations

I helped integrate Payload CMS so the site could move toward content ownership outside the codebase.

The CMS work supported:

• Structured page content.
• Reports.
• News.
• Product information.
• Reusable modules.
• Bilingual fields.
• Media.
• Future content growth.

Bilingual support

I designed and implemented patterns that supported both English and Arabic.

This included:

• Language routes.
• Right-to-left layout.
• Mirrored components where needed.
• Arabic typography.
• Content-length differences.
• Navigation behavior.
• Responsive QA.
• Arabic image and media requirements.

A broader website operating process

The project also produced a better way of working.

I helped create:

• Clearer ownership.
• Faster update paths.
• Reusable page patterns.
• A phased release method.
• QA practices.
• A content and CMS direction.
• A backlog for post-launch enhancements.
• A separation between application work and infrastructure tasks.

SEO and GEO improvements

I worked on changes that helped search engines and AI systems understand and surface the website.

This included technical and content changes across:

• Metadata.
• Page titles and descriptions.
• Headings.
• Alternative text.
• Internal links.
• Structured pages.
• Robots and sitemap behavior.
• Search indexing.
• Content rendering.
• Report naming.
• Discoverability.

Outcome

The project changed the website from a difficult static asset into a digital product with clearer ownership and a stronger technical base.

Key outcomes included:

• A modern visual experience that better reflected Lean.
• A clearer structure for products, solutions, reports, news, and company information.
• Responsive English and Arabic experiences.
• A reusable component system.
• A Next.js-based production architecture.
• A path for CMS-managed content.
• Faster delivery of new pages and updates.
• Stronger foundations for SEO, GEO, and AI discovery.
• Continued ownership rather than a one-time redesign.

A major operational improvement was the reduction in time needed for small and medium website updates.

Typical small-to-medium updates dropped from roughly two-to-four weeks to roughly one-to-four days.

I also tracked external audit improvements during the SEO work.

During the optimization phase, one tracked SEO audit score improved from 61.1 to 76.3.

The most important personal outcome was that the website became the first major production product where I combined design, front-end engineering, content, architecture, release work, and ongoing ownership.

It showed me how much I enjoy being responsible for a working product rather than stopping at a design handoff.

What I Learned

A website is an operating system for content

The visible pages are only one part of the product. The content model, CMS, components, ownership, and update process determine whether the site remains useful.

Product ownership changes the quality of decisions

When I was responsible for the result, I thought differently about scope, code quality, content, QA, and maintenance. I stopped asking only whether the design looked right and started asking whether the product could keep working.

Design and engineering improve each other

Implementing the front end helped me make better design decisions. Designing the experience helped me write components around real user and content needs.

Bilingual design must start early

Arabic support affects architecture, content, components, and QA. It cannot be added at the end without cost.

Content is part of UX

A strong layout cannot fix unclear content. The structure, wording, and order of information directly shape the user's understanding.

Reuse creates speed

A component system made it possible to deliver new pages and changes faster without losing consistency.

Launch is not completion

After launch, the work shifted toward content quality, CMS, indexing, search visibility, analytics, performance, and new ideas.

Technical dependencies need clear ownership

Some issues could be solved in the codebase. Others required access to DNS, Cloudflare, infrastructure, or external services. Separating those responsibilities made the work clearer.

SEO is a product concern

Search visibility depends on content, engineering, information architecture, and performance. It is not a final marketing task.

Exploratory work still has value

Not every 3D or interactive concept needed to ship. The explorations helped the team see how the website could move beyond standard corporate layouts in future versions.

I work best when I can own the outcome

This project confirmed that I am most engaged when I can connect the idea, design, technology, release, and iteration. It became an important part of my move from UX/UI into software and product engineering.