Calven is a B2B workplace platform built to empower hybrid workforces to plan, book resources, and provide a dynamic contextual experience for everyone from the ground floor to the C-Suite.
I’ve served as the lead product designer at Calven since May 2021 and have helped scale the product from an initial concept to a live multi-platform tool that serves thousands of users across companies of varying sizes.
Calven is a jack-of-all trades product when it comes to the workplace - which has given me experience working on an incredible breadth of features.
Automated, team-based planning and desk booking
Automated, team-based planning and desk booking
Realtime office floor map with desks and resources
Realtime office floor map with desks and resources
Office access control and presence automations
Office access control and presence automations
Coffee ordering and menu builder
Coffee ordering and menu builder
Resource usage analytics
Resource usage analytics
End-to-end events experience
End-to-end events experience
While I could spend plenty of time explaining any of the projects pictured above in detail (and would love to), I think it might be more interesting (and NDA-friendly) to highlight what working across such a breadth of features in a fast-paced tech environment has taught me in terms of my own design process. Here are some key things I’ve learned by doing during my time at Calven:
Know your (internal) audience 📢
This was huge when it came to learning what amount of effort to put in where. Creating a design to pitch an early concept to a stakeholder is an entirely different process compared to designing for a dev handoff. I quickly learned that the latter is where the real detail needs to go - documentation and edge cases need to be buttoned up and thought through, or else devs will be left unprepared - whereas the former is much more about telling a powerful story to the stakeholder, in as few steps as possible
Design in phases 🔢
As an early career designer, it was really easy to get caught up in creating a dream experience. While incredible levels of polish and delight are always the point to strive for, very rarely (in my experience) will a minimum viable product have everything that everyone wants. The most important thing I learned in that context is to be ready to kill my darlings - or at least strip them back to the simplest possible value to set them apart from the market. This is a principle that helped me immensely when working on something like an events tool - in which it’s easy to get caught up in industry standard features, but hard to narrow down on what we really want to do different.​​​​​​​
Distill feedback into goals, not specific features ✅
Often when working with stakeholders, especially founders and key business partners, everyone wants to be a designer. I always appreciate input, positive or negative, but it was important to learn not to take everything too literally. If someone demands a feature - I find it extremely valuable to distill that request into the form of a user story, i.e “As x person in y role, I want to solve z problem.” This helps avoid getting tunnel-vision when trying to solve a more complex problem, and keep the end goal in sight.
Always be scaling 📊
…or at least, thinking about scale. This might be a cliche, but it’s so important. I’ve learned (through plenty of trial and error) that an experience should never be designed in a vacuum, and if it doesn’t have a “generic” use case, it might not even be worth building. I find myself constantly asking - “how does this affect the rest of the experience, and what will it be used as a building block for?” That question has saved me from boxing myself into a limited future use case more than once.​​​​​​​
Summary 🏁
My time at Calven has allowed me to quickly dive right into the tech startup, B2B, SaaS world as a product designer with a lot of influence over a very large product. Since joining, I've spent lots of time working with internal and external stakeholders to gather research and feedback that would drive the direction of the product and define our roadmap, I've worked with engineers to parse business logic and translate designs to data and documentation, and of course - spent countless hours in Figma exploring, iterating, and prototyping to shape our product and the design system it was built upon.​​​​​​​

Other Projects

Back to Top