👈 Back home

Finanical Diligence Networks

FDN was a private platform for hedge funds and their investors, and it allowed each side to streamline their due diligence process. Here’s the current state of affairs: an investor, such as an endowment fund wants to invest in a hedge fund. To do so, they’ve got to do research on the hedge fund including asking questions of the fund directly with a questionnaire. Hedge funds receives a lot of these due diligence questionnaires each year, and since there is no standard format, they must respond to each individually. Resources are wasted by both the investor and the hedge fund.

The big idea at FDN was to create a platform that was kind of like LinkedIn and Dropbox for hedge fund due diligence. Hedge funds would create profiles about their firm’s performance, and investors would visit the profile and complete their own questionnaires. Hedge fund research streamlined.

I joined the small team at FDN in November of 2012 as their first and only designer. By then, they had an MVP that the founders had developed with Thoughtbot. The small engineering team and I focused on building new features to extend and grow the platform.

The biggest challenge was understanding the hedge fund investment domain, and learning what users needed from our platform to get their jobs done. We listened to how our users were doing their jobs currently, designed an built tools that would help them complete this work on our platform, then evaluated the efficacy of our work.

Helping investors take notes

Investors take a lot of notes when evaluating a hedge fund. Most investment firms have internal solutions for note-taking and sharing, ranging from proprietary systems built and maintained in-house, to services like Office 360. We decided to build a note-taking feature that would allow investors to take notes directly in FDN. Our goal was to be a turn-key solution to new and small investment funds.


Challenges and constraints

FDN was fast-moving startup working on a weekly sprint cycle. Frequently design and development was working simultaneously. Working in this way meant we broke this big feature into smaller iterations, released behind feature-flags, and necessitated a lot of decision-making on instinct and the domain knowledge of the team.

Design process


At group design sessions we would layout out the general direction of the feature as whiteboard and paper sketches before splitting off to draw wireframes, mockups, and prototypes 👇

Wireframes to mockups

As a designer/developer, I had to work from idea to code quickly, collaborating with developers who were simultaneously building the plumbing for the new feature. I iterated through hand-sketches, wireframes, and mockups 👇

Feature development

Once we had some confidence in the design and the developers had made enough progress, I hopped into the code base and write production-ready HTML and CSS, frequently making major changes on the fly in response to early internal and external testing 👇


FDN was as Ruby on Rails application, with a standard ERB, CoffeeScript, and SCSS stack.

👈 Back home