Lead UX Designer for the Bord remote collaboration whiteboarding app

Bord is a whiteboarding app that seeks to provide a simple and intuitive experience that users understand immediately. A key feature of the app is its ability to creates symbols and templates that make whiteboarding simple and easy, even for users that say they can’t draw. Role: Lead UX Designer -- worked with devs and the startup founder Industries: Remote working tools, whiteboarding, collaboration Tools used: Figma, Notion, Slack, Zoom, User Testing, Bord, Storyboard Duration: Initial MVP took 3 months, I continued as lead for 2 years

Understanding the Problem

Most important first step I always take is to step back and evaluate the problem being solved. I make sure that we are trying to solve the right problem and gather any information that will help frame the problem and come up with ideal solutions.
Competitive Analysis
The startup founder and I thoroughly researched and evaluated existing whiteboarding and collaboration tools. We compiled Notion pages summarizing our findings. We then whiteboarded remotely to consolidate our analysis into more concrete findings. From these findings we identified what problems our whiteboarding app would need to solve, potential stand-out features our app could have, and the business objectives.
Experimentation and Research
We then set out to rapidly storyboard and whiteboard different ideas for key differentiators that would separate our whiteboard app from competitors. We mapped out the journey the users would take in these various ideas as well as designed lo-fi concepts of how it could look.

User interviews were the next step, doing both quantitative anonymous surveys and testing as well as qualitative one-on-one interviews to get a better idea of what features our whiteboarding app should include.
Requirements and JIRA
Now that we had identified the features that the whiteboarding app would have, the startup founder and myself wrote out the requirements in JIRA with associated documentation in Notion. We then worked with the development team to prioritize the features based on dev difficulty so that we could determine what would be coded at each milestone working towards the completed MVP.

Ideation and Research

With a firm foundation from the competitive analysis, user interviews, and requirements, it was time to get started on the design work so that we could determine what the MVP will look like.
User Journey
When starting a new project from scratch, I find its always a good idea to determine what user personas or at least what kind of users will use this new feature and to map out their possible journeys through the UX for the project. Since this was a brand new company we developed a set of assumed user personas that we would modify and expand upon later.

I then proceeded to create journey maps and user flows for all of the MVP scenarios. This helped to identify any shortfalls, missing requirements, or potential issues, before I started mockups and design work.
Rapid Mockup Iteration
It was then time to move on to the solutioning phase. For each MVP feature, I started out by sketching out some ideas and then whiteboarding with the team to discuss my proposed solutions. Once we narrowed in on a few good options, I then rapidly produced higher quality prototypes that we could test with users to determine which of the UX solutions is the best and to refine the solutions based on their experiences and feedback using the prototypes.
User Research
We performed a mix of qualitative and quantitative research. UserTesting.com served as our main source fo of quantitative research as well as some simplistic asynchronous prototype testing. For more intensive qualitative research we used zoom for one-on-one interviews with potential customers, allowing them to try out prototypes and view potential concepts to get their feedback. This combination of research methodologies allowed us to have greater confidence that our MVP was ready to be coded.

The Solution

With greater confidence from the ideation and research phase, we moved to final MVP designs and coding. That was then followed by user testing with the live coded version.
1. Intuitive experience
One of the key driving features of Bord is the simplicity and intuitive nature of the UI. It needed to be immediately understood by the majority of users without any training or tutorials. To this end, I eliminated as much unnecessary UI elements as I could, creating a layered UI that progressively discloses more content as the user pushes deeper into the app. This way a beginner user can immediately pick up the app and use the whiteboard, however, a more advanced user can continually discover new features and more complex functionality.
2. Commenting
Since Bord is a remote working collaboration tool at its heart, the ability the collaborate via comments was hugely important. I performed a separate competitive and industry analysis to determine the best traits of the most used commenting systems. I settled on a system with comment threads attached to contextual pins on the canvas. The right panel serves as a place where the user can see a list of all the threads in a linear fashion without having to locate a thread on the canvas.
2. Symbols
The most common feedback we got from research and interviews with potential users was that they found most whiteboard tools were too difficult to use and made them feel bad for not being able to draw as well as their colleagues and collaborators. To mitigate this issue, I designed a system of symbols and templates so that users who don’t wish to draw can use customizable prefabricated designs. There is a common library of symbols across the Bord community as well as company specific symbols made by a user or their colleagues. Users can easily search and use symbols, much in the same way a user would look up an emoji in other apps. For more advanced users, its simple to create or edit a symbol from an existing drawing.
3. Templates
For more advanced use cases, I designed a template system and library. Unlike a standard whiteboard where all of the objects must be drawn or constructed from boxes and arrows, Bord’s templates would be very adaptable and customizable. For instance, a user could drop a table onto the whiteboard and add/remove rows and columns with simple controls rather than manually drawing a table and struggling to edit and expand it.

Over time I designed more and more templates, such as storyboards, roadmaps, venn diagrams, and more. Each was designed by myself, after which I would work with the dev team to turn it into a template with all the adjustable components it requires.