The launch posting process is potentially the single most important flow in the Product Hunt flywheel. It is how makers add their new launches to Product Hunt, with 30-40 new post that reach the homepage each day to be seen by our community.
As PH grew, the launch process grew more complex as new features were added and removed. However, the core experience remained the same -- new features ended up being shoehorned into a flow and architecture that wasn't originally designed to accomodate them.
When approaching the prospect of redesigning this key part of the experience, we had a couple of goals.
As I began this project, I leaned heavily on the expertise of our community team, who fields the support requests surrounding posting. Their feedback and familiarity with recurring maker support requests was invaluable throughout the process as we strategized, wireframed, and re-designed.
The first step in the post process was a jarring, brand-less, and lacking any context around what 'posting' entailed. In addition to a visual redesign, I worked with our support and content teams to craft content that would answer common questions at this stage of process. The questions would then adapt based on whether the maker was posting for the first time, or returning after a previous launch.
One of the key updates was adapting the process to support the introduction of drafts. Previously, there was no way to save an in-progress post – this meant you needed to have **all** your info ready to go at once. This resulted in frustration from users when they began the process and midway realized they didn't have all the information or assets needed to post...and there was no way to save progress
As new fields and features were added over the years, the "steps" had not changed. This resulted in an unclear IA in this flow – it wasn't immediately obvious what content belonged in which step of the flow.
I did an audit of all the fields we wanted/needed for launches and re-organized this data into a series of steps that was more in line with how makers thought about product launches. With this new series of steps, I was also able to work collaboratively with our engineering team to determine what our autosave and draft experience could support.
In my discussions with our community team, I identified an interesting issue tied to moderation. We had a high percentage of launches that would be submitted, but not featured because they didn't meet some of our guidelines. Unfortunately, this was mostly our fault, as the process made it difficult for makers to understand what these guidelines actually were.
In an effort to reduce reliance on moderation and have more launches that don't require intervention, we worked on the UX microcopy and introduced a new 'Launch Checklist' step that would review both the required AND suggested fields in the process.
The updated experience launched to positive feedback from our community. Drafts in particular got a lot of love. We were able to further validate the success of these changes with reduced support requests related to posting, a decrease in manual moderation and a significant increase in the percentage of products including the "suggested" information –– indicating that our launch checklist page was having a positive effect.