Hitchology

Project: Hitchology
Start Date: 2011
Role: Product Manager, Product/Brand Designer

---

The Problem and Opportunity

---

Hitchology began as a vision to be a one-stop shop for wedding coordinators and morphed into a shared web app for wedding coordinators and couples to plan weddings. I came into this process as the project lead and product/brand designer.

At the time we began this project all major wedding coordination websites were cluttered, poorly designed and subpar in terms of tools. The success of this web application hinged on our ability to translate the couples needs into a simple seamless design. We also had to challenge a bride-focused industry by providing an experience for both the groom and bride. We were reaching out to a new market: the groom.

We wanted to stand out not only visually but also because of the experience we were providing for users to work together.

---

The Tasks

---

• Take the clients vision and translate it into deliverables
• Lead a team to conceptualize, plan and build a solid web application with over a dozen features
• Challenge the standards of the competition and focus on Hitchology’s unique offerings
• Maintain an adaptable approach to business plan changes as while continually updating contract terms

---

The Process

---

Step 1: Understand the competition and plan a unique feature set.

The first feature to stand out was that we wanted to advertise not only to the bride but also the groom. This feature brought with it unique challenges as we had to think about how the users would both share tasks and budget but also keep things separate. As we began to think through our database this feature was the forefront of our thinking and planning.

Our second feature that set us apart wasn’t in the initial contract or database build-out. As we were doing research on what couples needed and what no one else in the industry was offering we stumbled upon a feature called the address collector. This was the age when people were sending out Facebook messages to all their contacts asking for their address for a wedding invite. We changed our project scope and built a way for people to send/text out a link to their friends where they could input their address. Though we had to redo parts of our database we felt like the added value was worth it.

Step 2: Build a solid database to handle the complexity.

As we thought through all the different stages and choices users could make we continually adjusted our database plan.

A lesson I learned during this phase was to have a very clear plan going into database planning meetings. Sometimes we would spend hours talking through one small feature. Even though it was imperative to think through the small details we learned to first work through everything we knew. In those conversations if an item was taking longer than our allotted time I often would cap that conversation for later. Following the meetings we would think through the pros and cons of the different options.

I found that if we let those decisions simmer for a few days a third and better options would often emerge. Giving space to create alternatives apart from the collective group was valuable to our team.

Step 3: Wireframe the UI and begin application development.

Hitchology has over a dozen applications a part of it’s design so as you can imagine the UI design took countless hours. I learned the value of working out UI design through multiple feedback phases before taking the time to actually make a “beautiful” design. As someone who is a perfectionist and detailed designer it isn’t natural for me to invite test users into the “messy” wireframe stage. However, this practice of working out user and our developer feedback before final front end design was imperative.

Step 4: Develop branding and apply design to the UI.

The vision for the initial product took about a year to finalize. In fact, about 6 months into the design phase, based on user feedback the name was changed from Colure to Hitchology. As we had already went through a very thorough branding process with many iterations we made the new name work within that brand.

The branding for this project actualized in 2012. During this time white space was become a new design feature. We decided to go with a color palette that wasn’t feminine but pared it with elegant and simple typography. Letterpress was becoming more affordable in the print industry and companies were developing brands that utilized that texture. A sign of sophistication for wedding invites was letterpress which we decided to mimic. We went with a simple theme that utilized that texture. In 2012, the iPhone was gaining popularity and the use of icon badges was becoming a familiar way of communication. i emphasized skumorphic design by the use of textures, shading and layering to mimic letterpress paper and follow the app design trends. Our design stood out amongst the competitors.

Step 5: Test, finalize and launch Hitchology.com.

We launched a few applications at a time within the site and worked with beta and actual users to fine tune the features. Once we felt good about how users were responding and working in the system we would launch another feature. This took us about a year or more to launch the programs.

The process of getting actual user data was helpful in determining what was working and what wasn’t and how we could simplify. In my contract with the owner part we agreed to a phase where we would edit programs, UX, UI based on actual user data.

Most of the programs in Hitchology.com were launched in 2014.

Though the UI design is currently out of date, the UX and database design has stood the test of time and still provides couples with an excellent wedding coordination experience.