Josh Koh
All Work

District 9 Website · Honolulu City Council

Launching a Civic Platform for Honolulu City Council District 9

Project Tags:Product DesignGov / Civic UXInfo Architecture
District 9 Website / Intro1920 × 1080

01 Overview

113,000 Residents, No Front Door

District 9 covers close to 113,000 residents, but only about 800 were signed up to hear from the office directly, and everyone else relied on social media, mailers, or word of mouth. The Councilmember's page lived inside a shared Honolulu City Council site built on Squarespace, with no way to publish a story, brand the page, or take in a resident's concern.

As the office's sole product designer, I researched, designed, and shipped District 9's first dedicated civic platform. The newsletter it unlocked saw click-through jump 267% within three weeks of launch.

02 Context

Built for Nine Offices, Not One

The office reached people the way a lot of local government offices do, through social media, physical mailers, and showing up in the community. The Councilmember's page on the shared council site was the closest thing to a website, but it wasn't built to function as one.

What It Couldn't Do

  • Publish a story or update on its own
  • Take in a resident's concern beyond a generic form that dumped into a shared inbox
  • Reflect any branding specific to District 9
  • Support a resource page or a dedicated District 9 newsroom, since the underlying system was a Squarespace site shared across nine offices with a page cap and no real content model behind it, not a CMS built for districts with different needs

District 9 needed something of its own, built for how residents actually try to get help, not fit inside a system built for nine offices at once.

That gap showed up most clearly in the newsletter. With no site to send people to, every story had to be written out in full inside the email itself, dense blocks of text with no way to skim and no reason to click.

After: the new District 9 homepage, “Connecting our residents to services and resources.”Before: the Councilmember's subpage on the shared council site.BeforeAfter
Before/After: The previous experience was a subpage that was somewhat buried. The new site is now a dedicated page for all things District 9.

03 Problem

Two Sides of the Same Gap

Residents

Resident-Facing Issue

Residents knew a councilmember existed. What they didn't have was a reliable way to act on that.

  • No clear sense of what the office actually did or which services were theirs to ask for
  • No clean understanding if an issue they were reporting was a city or state matter
  • If they did find a way to submit online, they had no confirmation message, no follow-up action items, and no way to know if anyone had seen their request

Office

Internal Office Issue

The office had a fragmented intake experience with no shared channel underneath it.

  • Calls came in one way, with no shared record once the call ended
  • Social media brought DMs and comments in at a volume that made real requests hard to separate from passing comments
  • Email was the weakest link of all, a resident had to already know the office's address by memory or go hunting for it.

Eleven interviews in, three different residents said almost the same sentence, unprompted: you don't know what you don't know.

The website was the missing piece that could have made all three actually work as one system.

Problem statement

Residents lacked a reliable way to find help or know if reaching out worked. The office lacked a reliable way to reach residents beyond a feed people scrolled past, or to know when a request had gone unanswered.

04 Research

You Don’t Know What You Don’t Know

Before talking to residents, I sat down with Marcia, the Chief of Staff, and Aaron, the constituent affairs specialist for ʻEwa Beach, to understand what the office actually needed a website to do. Their feedback split into three clear goals.

  1. A permanent home for news and updates, since anything posted to social got buried the next day and anything sent in the eblast went unread if it ran too long
  2. A way to grow real engagement, meaning more residents subscribed to the newsletter, not just following on social
  3. A starting point for residents who had no idea who to contact, what the office actually did, or where city responsibility ended and state began

Those three goals became direct throughlines. The Newsroom answered the first, the newsletter subscribe placement answered the second, the IA and persistent FAQ answered the third.

Affinity mapping · Research highlights

What Residents Told Us

60 observations sorted into 8 themes. These 38 are the ones that shaped the redesign. Pick a theme to read it, or a resident to follow their notes.

60
observations
8
themes
38
highlights
Affinity mapping highlights from 11 constituent/resident interviews. Every note is a real quote or observation.

I also surveyed all 800 newsletter subscribers and got 178 responses back, enough to see real patterns across the district rather than guess from a handful of loud voices. Between the stakeholder conversations, the interviews, and the survey, I had both sides of the problem in view, what residents experienced, and what the office needed the site to do for them.

What Came Back, Again and Again

  • 70% of respondents didn't know the office had any web presence at all
  • Almost every resident who had tried to get help described the same pattern, unclear if the issue was city or state, no confirmation after submitting, no timeline, no sign anyone had seen it
  • Responsiveness mattered more than polish as a trust signal, since silence did more damage than any confusing page ever could
  • Almost nobody started their search for help on a government website, discovery started on Google, social media, or by asking a neighbor

The site couldn't assume anyone would start there. It had to work just as well for someone arriving from a Google search, a social post, or a friend's text as it would for someone who typed the address in directly.

05 Validation

Putting Early Designs in Front of People

I conducted a second round of interviews, 12 people this time, 3 staff and 9 residents, a mix of District 9 residents and other Honolulu constituents, to see whether the first iteration of high-impact areas like the homepage, resources, and news actually worked and was intuitive for the user.

Want to see initial designs and the primary areas with issues? Take a look and interact below!

Hi-fi designs · What we heard

Did It Work? Not Fully.

Three things came back consistently from staff and nine residents. Step through each finding and see exactly where it landed on the page.

Finding 1 of 5

The headline doesn't say what District 9 covers

It welcomes residents in, but they came away without knowing what the office actually does.

What we heard on Home

Inviting, but vague

Staff, including the Chief of Staff, said the homepage didn't make clear what District 9 actually covers, and the header put browsing ahead of the one action that mattered most.

8 of 9residents still didn't know what District 9 was after looking at it
Chief of Staffwanted an easy way to report a problem to lead the header

06 Design Solutions

Four Decisions, One Civic Platform

These are the four decisions that took District 9 from a shared council subpage to a standalone civic platform. Each one closes a gap that had no digital equivalent before this site existed.

SOLUTION 01

Clearly Designating a Place to Report a Problem, for the First Time

A resident with a pothole or a broken streetlight had three scattered options: a phone call, social media DMs, or a direct email address if they already had access to one. The gap missing was a unified online experience. Surfacing "Report a District Issue" as one of the initial touch points gives residents an actual place to go.

The Problem

The old subpage's only interactive element was a generic contact form feeding a shared inbox that was shared by the staff. Everything else arrived through calls or DMs, with nothing tying any of it together.

The Solution

A dedicated nav item and structured form gave residents an online reporting path that had never existed. The office now receives 5 to 10 submissions a week, some new, some overlapping with calls.

After: the District 9 “Report a District Issue” form.Before: the generic contact form on the old subpage.BeforeAfter

Since launch, the office manager has been receiving 5 to 10 structured submissions a week, routed to the constituent affairs specialists covering 'Ewa Beach and Waipahu, some overlapping with calls already received, others entirely new.

SOLUTION 02

Developing a Comprehensive Online Repository of News and Updates

The office was doing real work every week and featuring initiatives out in the community, but there was no established place for these stories to live. I built District 9's first newsroom, with real content categories so staff could publish updates as they happened and let that work live somewhere permanent.

The Problem

The old subpage used quick links that routed to other articles as its "news section" since there was no content model built for it. We featured articles other people wrote, but didn't have the capabilities to share our own.

The Solution

A permanent and dedicated newsroom created a home for District 9 content to live in permanence, as well as gave residents the ability to browse by specific article types for ease of use.

After: the District 9 newsroom with article categories.Before: the old “In the news” quick links.BeforeAfter

SOLUTION 03

A Newsletter With Somewhere to Send People

Every eblast the office sent had to carry entire stories in the body of the email, because there was nowhere else to send anyone. Once the site existed, I rebuilt the newsletter around it, replacing a one-off contact CTA with "Subscribe to Newsletter," built with Codex.

The Problem

With no site to publish to, the monthly eblast had to carry every story in full inside the email. The old subpage had no subscribe mechanism, only that same generic form.

The Solution

A real home for content let the eblast shift to scannable headlines linking back, and a direct subscribe action gave residents a way onto the list that had never existed.

After: the ʻEwa Beach newsletter with scannable story cards.Before: a dense monthly overview email with full stories inline.BeforeAfter

SOLUTION 04

Creating a Resource Hub Where None Existed

For years, a resident looking for help from District 9 had nowhere to actually look. I built the office's first resource hub, splitting it into three sections, District 9 Resources, City Resources, and Community Programs, so residents finally had somewhere to land.

The Problem

The old subpage had minimal resource content and users kept calling in about resource based questions. Jurisdictional confusion was one of the top reasons residents described giving up.

The Solution

The site now establishes a place for resources, organized by what a resident is trying to do, what department owns what, and what community initiatives are available for District 9 residents.

After: the District 9 resource hub.Before: no dedicated resources section on the old subpage.BeforeAfter

07 Working with AI

When Codex Became the Engineer

Two features needed real functionality beyond what Framer's native tools supported, the newsletter subscribe form with Mailchimp integration, and the events table. I used Codex as the implementation partner for both. My part was specifying exactly how each feature needed to behave, what fields the subscribe form needed to capture, how the events table needed to sort and display, then reviewing and testing every part of what came back before it shipped.

Those are decisions that would normally sit with an engineer. Without one on staff, they sat with me.

Here's a preview of my prompt iteration process with codex and building a functional subscription model.

Codex / Prompt iterationsVideo

08 Constraints

One Designer, Every Phase

I ran this without a dedicated product team, but not without a team.

  • No product manager. I scoped every phase myself, research, design, content, CMS, launch.
  • No engineer. Anything beyond what Framer's native tools supported went through Codex, with me specifying behavior and reviewing every output.
  • No dedicated researcher. I ran both interview rounds myself, training a colleague to help conduct sessions rather than handing the work off.
  • Real feedback, just no shared ownership. The Chief of Staff, the former office manager, the constituent affairs specialist for 'Ewa Beach, and Councilmember Tulba, the full office of seven, all shaped decisions along the way. None of them could own a phase alongside me.

Without a team to catch what I missed, every pathway and feature had to be intentional, there wasn't a second designer or a PM to flag it if it wasn't.

That same weight is why WCAG compliance didn't make it into this version. Rather than force it in under pressure, I shipped an interim accessibility widget once the federal deadline for government sites moved to 2027, and set full compliance as a defined V2 priority instead.

09 Outcomes

Early Signals, and a 267% Jump

The clearest early signal is the newsletter. Once stories had a real place to live, the first eblast after launch saw click-through jump from 0.9% to 3.3% in three weeks, a 267% increase.

One send isn't a trend yet. I'll know more once the next one goes out at the end of the month. But this isn't a one-time trick, the scannable card format is now the standing structure for every future eblast, not a redesign done for a single send.

Two newsletter dashboards comparing click-through rates before and after launch.
Newsletter click-through rate increased by 267%. A look at the CTR rates before and after launch

What's Holding Steady Every Week Since:

  • 5 to 10 structured issue reports come through the site weekly
  • Each one routes directly to the constituent affairs specialists for 'Ewa Beach and Waipahu
  • Some overlap with calls already received, others are entirely new issues that never surfaced through a call or a DM before
  • The Chief of Staff has pointed to the visibility this gives the office as something calls and social messages alone never offered

10 Lessons Learned

What Leading the Whole Build Taught Me

  1. Being the only product person on the team sharpens judgment, it doesn't just test patience. With no one else to catch what I missed, I stopped treating decisions as reversible later. Every choice had to be right the first time.
  2. Precision with AI is a design skill, not a technical one. Codex only does exactly what you tell it, nothing more generous than that. I learned that writing instructions specific enough to survive that turned out to be the same discipline as writing a clear spec, just aimed at a different reader.
  3. Visibility earns trust faster than volume does. The office wasn't short on effort, mailers, posts, eblasts were already happening. What was missing was one place sturdy enough that people believed it and came back.
  4. Community trust doesn't start at zero. Residents already had ways of getting help, a neighbor, a church bulletin, a family member who translates. The site didn't need to invent trust from nothing, it had to earn a place inside relationships that already existed.

11 Next Steps

Proving It Keeps Working

Full WCAG compliance is still ahead of me, and multilingual support for the ESL households research kept surfacing needs real attention instead of staying a known gap.

I'm also looking at pushing Codex further, past fixed features like the subscribe form, into parts of the site that can respond and adapt on their own. I don't have the exact shape of that locked in yet, but it's the direction I'm exploring next.

Ninety days out from launch, I'm planning to go back to residents with a short pulse survey, reaching the original 178 subscribers plus a wider push through social media, to see what's actually working, what isn't, and what gaps only show up after someone has used the site for a while instead of just visiting it once.

The platform did its job at launch. Whether it keeps doing that job is the next step to prove.

01 Overview

113,000 Residents, No Front Door

District 9 covers close to 113,000 residents, but only about 800 were signed up to hear from the office directly, and everyone else relied on social media, mailers, or word of mouth. The Councilmember's page lived inside a shared Honolulu City Council site built on Squarespace, with no way to publish a story, brand the page, or take in a resident's concern.

As the office's sole product designer, I researched, designed, and shipped District 9's first dedicated civic platform. The newsletter it unlocked saw click-through jump 267% within three weeks of launch.

02 Context

Built for Nine Offices, Not One

The office reached people the way a lot of local government offices do, through social media, physical mailers, and showing up in the community. The Councilmember's page on the shared council site was the closest thing to a website, but it wasn't built to function as one.

What It Couldn't Do

  • Publish a story or update on its own
  • Take in a resident's concern beyond a generic form that dumped into a shared inbox
  • Reflect any branding specific to District 9
  • Support a resource page or a dedicated District 9 newsroom, since the underlying system was a Squarespace site shared across nine offices with a page cap and no real content model behind it, not a CMS built for districts with different needs

District 9 needed something of its own, built for how residents actually try to get help, not fit inside a system built for nine offices at once.

That gap showed up most clearly in the newsletter. With no site to send people to, every story had to be written out in full inside the email itself, dense blocks of text with no way to skim and no reason to click.

After: the new District 9 homepage, “Connecting our residents to services and resources.”Before: the Councilmember's subpage on the shared council site.BeforeAfter
Before/After: The previous experience was a subpage that was somewhat buried. The new site is now a dedicated page for all things District 9.

03 Problem

Two Sides of the Same Gap

Residents

Resident-Facing Issue

Residents knew a councilmember existed. What they didn't have was a reliable way to act on that.

  • No clear sense of what the office actually did or which services were theirs to ask for
  • No clean understanding if an issue they were reporting was a city or state matter
  • If they did find a way to submit online, they had no confirmation message, no follow-up action items, and no way to know if anyone had seen their request

Office

Internal Office Issue

The office had a fragmented intake experience with no shared channel underneath it.

  • Calls came in one way, with no shared record once the call ended
  • Social media brought DMs and comments in at a volume that made real requests hard to separate from passing comments
  • Email was the weakest link of all, a resident had to already know the office's address by memory or go hunting for it.

Eleven interviews in, three different residents said almost the same sentence, unprompted: you don't know what you don't know.

The website was the missing piece that could have made all three actually work as one system.

Problem statement

Residents lacked a reliable way to find help or know if reaching out worked. The office lacked a reliable way to reach residents beyond a feed people scrolled past, or to know when a request had gone unanswered.

04 Research

You Don’t Know What You Don’t Know

Before talking to residents, I sat down with Marcia, the Chief of Staff, and Aaron, the constituent affairs specialist for ʻEwa Beach, to understand what the office actually needed a website to do. Their feedback split into three clear goals.

  1. A permanent home for news and updates, since anything posted to social got buried the next day and anything sent in the eblast went unread if it ran too long
  2. A way to grow real engagement, meaning more residents subscribed to the newsletter, not just following on social
  3. A starting point for residents who had no idea who to contact, what the office actually did, or where city responsibility ended and state began

Those three goals became direct throughlines. The Newsroom answered the first, the newsletter subscribe placement answered the second, the IA and persistent FAQ answered the third.

Affinity mapping · Research highlights

What Residents Told Us

60 observations sorted into 8 themes. These 38 are the ones that shaped the redesign. Pick a theme to read it, or a resident to follow their notes.

60
observations
8
themes
38
highlights
Affinity mapping highlights from 11 constituent/resident interviews. Every note is a real quote or observation.

I also surveyed all 800 newsletter subscribers and got 178 responses back, enough to see real patterns across the district rather than guess from a handful of loud voices. Between the stakeholder conversations, the interviews, and the survey, I had both sides of the problem in view, what residents experienced, and what the office needed the site to do for them.

What Came Back, Again and Again

  • 70% of respondents didn't know the office had any web presence at all
  • Almost every resident who had tried to get help described the same pattern, unclear if the issue was city or state, no confirmation after submitting, no timeline, no sign anyone had seen it
  • Responsiveness mattered more than polish as a trust signal, since silence did more damage than any confusing page ever could
  • Almost nobody started their search for help on a government website, discovery started on Google, social media, or by asking a neighbor

The site couldn't assume anyone would start there. It had to work just as well for someone arriving from a Google search, a social post, or a friend's text as it would for someone who typed the address in directly.

05 Validation

Putting Early Designs in Front of People

I conducted a second round of interviews, 12 people this time, 3 staff and 9 residents, a mix of District 9 residents and other Honolulu constituents, to see whether the first iteration of high-impact areas like the homepage, resources, and news actually worked and was intuitive for the user.

Want to see initial designs and the primary areas with issues? Take a look and interact below!

Hi-fi designs · What we heard

Did It Work? Not Fully.

Three things came back consistently from staff and nine residents. Step through each finding and see exactly where it landed on the page.

Finding 1 of 5

The headline doesn't say what District 9 covers

It welcomes residents in, but they came away without knowing what the office actually does.

What we heard on Home

Inviting, but vague

Staff, including the Chief of Staff, said the homepage didn't make clear what District 9 actually covers, and the header put browsing ahead of the one action that mattered most.

8 of 9residents still didn't know what District 9 was after looking at it
Chief of Staffwanted an easy way to report a problem to lead the header

06 Design Solutions

Four Decisions, One Civic Platform

These are the four decisions that took District 9 from a shared council subpage to a standalone civic platform. Each one closes a gap that had no digital equivalent before this site existed.

SOLUTION 01

Clearly Designating a Place to Report a Problem, for the First Time

A resident with a pothole or a broken streetlight had three scattered options: a phone call, social media DMs, or a direct email address if they already had access to one. The gap missing was a unified online experience. Surfacing "Report a District Issue" as one of the initial touch points gives residents an actual place to go.

The Problem

The old subpage's only interactive element was a generic contact form feeding a shared inbox that was shared by the staff. Everything else arrived through calls or DMs, with nothing tying any of it together.

The Solution

A dedicated nav item and structured form gave residents an online reporting path that had never existed. The office now receives 5 to 10 submissions a week, some new, some overlapping with calls.

After: the District 9 “Report a District Issue” form.Before: the generic contact form on the old subpage.BeforeAfter

Since launch, the office manager has been receiving 5 to 10 structured submissions a week, routed to the constituent affairs specialists covering 'Ewa Beach and Waipahu, some overlapping with calls already received, others entirely new.

SOLUTION 02

Developing a Comprehensive Online Repository of News and Updates

The office was doing real work every week and featuring initiatives out in the community, but there was no established place for these stories to live. I built District 9's first newsroom, with real content categories so staff could publish updates as they happened and let that work live somewhere permanent.

The Problem

The old subpage used quick links that routed to other articles as its "news section" since there was no content model built for it. We featured articles other people wrote, but didn't have the capabilities to share our own.

The Solution

A permanent and dedicated newsroom created a home for District 9 content to live in permanence, as well as gave residents the ability to browse by specific article types for ease of use.

After: the District 9 newsroom with article categories.Before: the old “In the news” quick links.BeforeAfter

SOLUTION 03

A Newsletter With Somewhere to Send People

Every eblast the office sent had to carry entire stories in the body of the email, because there was nowhere else to send anyone. Once the site existed, I rebuilt the newsletter around it, replacing a one-off contact CTA with "Subscribe to Newsletter," built with Codex.

The Problem

With no site to publish to, the monthly eblast had to carry every story in full inside the email. The old subpage had no subscribe mechanism, only that same generic form.

The Solution

A real home for content let the eblast shift to scannable headlines linking back, and a direct subscribe action gave residents a way onto the list that had never existed.

After: the ʻEwa Beach newsletter with scannable story cards.Before: a dense monthly overview email with full stories inline.BeforeAfter

SOLUTION 04

Creating a Resource Hub Where None Existed

For years, a resident looking for help from District 9 had nowhere to actually look. I built the office's first resource hub, splitting it into three sections, District 9 Resources, City Resources, and Community Programs, so residents finally had somewhere to land.

The Problem

The old subpage had minimal resource content and users kept calling in about resource based questions. Jurisdictional confusion was one of the top reasons residents described giving up.

The Solution

The site now establishes a place for resources, organized by what a resident is trying to do, what department owns what, and what community initiatives are available for District 9 residents.

After: the District 9 resource hub.Before: no dedicated resources section on the old subpage.BeforeAfter

07 Working with AI

When Codex Became the Engineer

Two features needed real functionality beyond what Framer's native tools supported, the newsletter subscribe form with Mailchimp integration, and the events table. I used Codex as the implementation partner for both. My part was specifying exactly how each feature needed to behave, what fields the subscribe form needed to capture, how the events table needed to sort and display, then reviewing and testing every part of what came back before it shipped.

Those are decisions that would normally sit with an engineer. Without one on staff, they sat with me.

Here's a preview of my prompt iteration process with codex and building a functional subscription model.

Codex / Prompt iterationsVideo

08 Constraints

One Designer, Every Phase

I ran this without a dedicated product team, but not without a team.

  • No product manager. I scoped every phase myself, research, design, content, CMS, launch.
  • No engineer. Anything beyond what Framer's native tools supported went through Codex, with me specifying behavior and reviewing every output.
  • No dedicated researcher. I ran both interview rounds myself, training a colleague to help conduct sessions rather than handing the work off.
  • Real feedback, just no shared ownership. The Chief of Staff, the former office manager, the constituent affairs specialist for 'Ewa Beach, and Councilmember Tulba, the full office of seven, all shaped decisions along the way. None of them could own a phase alongside me.

Without a team to catch what I missed, every pathway and feature had to be intentional, there wasn't a second designer or a PM to flag it if it wasn't.

That same weight is why WCAG compliance didn't make it into this version. Rather than force it in under pressure, I shipped an interim accessibility widget once the federal deadline for government sites moved to 2027, and set full compliance as a defined V2 priority instead.

09 Outcomes

Early Signals, and a 267% Jump

The clearest early signal is the newsletter. Once stories had a real place to live, the first eblast after launch saw click-through jump from 0.9% to 3.3% in three weeks, a 267% increase.

One send isn't a trend yet. I'll know more once the next one goes out at the end of the month. But this isn't a one-time trick, the scannable card format is now the standing structure for every future eblast, not a redesign done for a single send.

Two newsletter dashboards comparing click-through rates before and after launch.
Newsletter click-through rate increased by 267%. A look at the CTR rates before and after launch

What's Holding Steady Every Week Since:

  • 5 to 10 structured issue reports come through the site weekly
  • Each one routes directly to the constituent affairs specialists for 'Ewa Beach and Waipahu
  • Some overlap with calls already received, others are entirely new issues that never surfaced through a call or a DM before
  • The Chief of Staff has pointed to the visibility this gives the office as something calls and social messages alone never offered

10 Lessons Learned

What Leading the Whole Build Taught Me

  1. Being the only product person on the team sharpens judgment, it doesn't just test patience. With no one else to catch what I missed, I stopped treating decisions as reversible later. Every choice had to be right the first time.
  2. Precision with AI is a design skill, not a technical one. Codex only does exactly what you tell it, nothing more generous than that. I learned that writing instructions specific enough to survive that turned out to be the same discipline as writing a clear spec, just aimed at a different reader.
  3. Visibility earns trust faster than volume does. The office wasn't short on effort, mailers, posts, eblasts were already happening. What was missing was one place sturdy enough that people believed it and came back.
  4. Community trust doesn't start at zero. Residents already had ways of getting help, a neighbor, a church bulletin, a family member who translates. The site didn't need to invent trust from nothing, it had to earn a place inside relationships that already existed.

11 Next Steps

Proving It Keeps Working

Full WCAG compliance is still ahead of me, and multilingual support for the ESL households research kept surfacing needs real attention instead of staying a known gap.

I'm also looking at pushing Codex further, past fixed features like the subscribe form, into parts of the site that can respond and adapt on their own. I don't have the exact shape of that locked in yet, but it's the direction I'm exploring next.

Ninety days out from launch, I'm planning to go back to residents with a short pulse survey, reaching the original 178 subscribers plus a wider push through social media, to see what's actually working, what isn't, and what gaps only show up after someone has used the site for a while instead of just visiting it once.

The platform did its job at launch. Whether it keeps doing that job is the next step to prove.

please feel free to browse other case studies below!

More Case Studies

Back to Projects
© 2026 Josh KohDesigned by me · Built with codeBack to top