Hatchful CMS

The initial project kickoff consisted of meeting with multiple members of the Hatchful team, to fully understand the problem space. I spoke with the primary user, the logo designer, who will be the person that uploads the logo, a few developers, who work with the templates that are in staging and push to production, and lastly the project manager, who oversees all initiatives regarding Hatchful. Throughout these interviews I used tools such as journey mapping and personas to fully understand the problem space in the user’s position.

Once all the necessary features and capabilities were gathered, I began defining each as an actionable item a user can complete. Next, 8 participants, each with different backgrounds (design, development, operations) were recruited to complete a card sorting study in person. From the results, which consisted of continuous feedback and explanations the participants were giving when walking me through their process, I gained a stronger understanding of how to organize the information. The studies also brought up a few edge cases and uncertainties that needed to be addressed when designing the solution.

After the studies were completed, I added the results to OptimalSort to generate similarity charts. From here, I could accurately analyze problematic areas to pin-point which actions were the most confusing for the user. This step ensures that the hierarchy tree designed will be easily understood by most, if not all users. This tree is also very helpful in syncing with the team; using it as a visualization tool in how the CMS will be laid out.

Syncing with the developers early on in the process is always beneficial especially when building out a massive project such as a CMS. After all the foundational information architectural work had been completed, I shared some of the results and findings from the card sorting studies and the interviews. I then walked through the hierarchy tree, which laid out all the actions that can be completed using the CMS. This meeting was mainly an open discussion as to what is possible / needed for version 1 of the CMS. After this meeting, a clearly defined Scope Doc was written up to document what will be designed into v1.

Taking the scope doc and hierarchy tree, I first created rough wireframes, trying a few different navigational styles such as implementing a sidebar, top navigation, and initial launch screen. The next major aspect of the CMS was to design the multi-editing experience,ince one of the major pain points identified was the inability to tag and add new editing features to multiple logo templates at once. After defining the main actions on each screen and how they would translate from screen to screen, I began designing the hi-fi layouts. Because this was an internal tool, visual design and styling was not the main priority. The hi-fi designs consisted of a simple grid layout with a sidebar navigation (best for scaling the product with new features) and task actions held at the top of the screen where it was the most accessible. Sorts and filters were implemented to easily toggle between states (staging vs. production) and different categories that the logo templates lived in. The screens underwent many design reviews and iterations before being prepped for developer hand-off.