Katch
Flexible meetings with real time availability
Please note that the design deliverables included in this case study are for reference only and may not match the final designs used by Katch.
Additionally, none of the information, deliverables, or design decisions presented in this case study represent the views or opinions of Katch.
Katch is a US-based early-stage startup with less than 20 employees. At the time I joined the company as the only UX/UI designer on the team, the product was in the private beta stage.
Throughout my time with Katch, I have...
1. worked closely with the Head of Product, conducting and participating in daily standups and brainstorming sessions,
2. designed a Slack prototype as at the time we deemed it to be the ideal medium to conduct user research and observe user behaviors, though never shipped it, and
3. re-designed several primary features for the Katch iOS app, and conducted discussion sessions with the Head of Product and the dev team.
"I very much enjoyed working with Goksu for a couple of months when he came on board as a product designer, he was my main partner in discussions about the overall product value proposition. Goksu demonstrated strong analytical skills and could easily grasp the whole user journey from the first day of his work, which really impressed me. Thanks to his user empathy skills he helped us redesign the navigation of the app and worked on a slack app which is still to be implemented. Goksu can challenge ideas that make him a great team member and I can envision he is going to have a great career in user experience design."
After a quick onboarding that brought me up to speed, getting me to know about the issues that the product was facing at the time, the Head of Product and I conducted several brainstorming sessions to decide on the best medium to test the product-market fit and primary/secondary features.
We concluded that a Slack app would be the ideal medium as it is easy to prototype, it is relatively quick to develop, and, most importantly, most of our target audience would use Slack as part of their professional life regularly.
Around the time we had just started working on this Slack app, we considered two different forms of availability that I called "local availability" and "global availability".
Local availability: A person would be locally available when they signal that they are available to the people who sent meeting requests at a prior date or to a pre-selected group of people. This could be called "selective availability" as well.
Global availability: A person would be globally available when they signal that they are available to everyone. This could be called "unselective availability" as well.
The reason why we considered this concept of local availability was that in some very large companies, signaling that you are (globally) available to everyone on your Slack channel means that hundreds of people would be able to request meetings, making it extremely hard for the user to maintain.
For reasons that I was not informed of at the time, we were asked to quit working on the Slack app and move to work on the iOS app that the company was already developing at the time I joined.
Shortly after, per some changes in the company's short-term plan, the executive team set a date for a Product Hunt launch and to make sure that we do not miss the deadline, we had to work in a very agile manner, redesigning primary features and preparing/ explaining handoffs to engineers in an almost bi-daily manner to complete the Katch iOS app.
As my seniors were worried that the product was bloated with many features, the Head of Product and I were asked to work on and re-design some hand-picked features that were considered necessary for the optimal user experience. Those three key features were Availability Hours, Marking as Done, and Sending Meeting Requests.
Availability Hours helps the user to get more timely reminder notifications from the Katch iOS app.
Thanks to a new user flow we came up with, our users no longer need to turn on/off this feature, enhancing the user experience immensely.
To make sure that the user interface is not bloated with inactive meeting request cards, we enabled our users to mark as done and remove them from their interfaces.
Despite my concerns about using checkboxes to select cards, due to the time constraints, we had to go with it.
I considered this to be a questionable decision as (1) checkboxes commonly are not used for this function, and (2) the home screen layout lost its consistent visual alignment.
More on this feature later.