Addepar Report Editor

July 2013 – April 2014

The report editor in the Addepar web product.



Wealth managers routinely need to communicate progress and data to their clients and colleagues. However, financial reports are incredibly tedious to create, taking as much as a week every month or quarter. This is the result of two key factors:

  • No central data platform that hosts clients’ data
  • No integrated tool to create and publish reports on that data

Addepar provides a consolidated data and reporting platform that allows wealth managers to interact directly with the report, and automates the laborious publishing process. The report editor has been designed using existing design patterns to satisfy wealth managers’ specific workflows and has innovative features such as portfolio context switching, linked sections, and advanced widget behaviour in tables and text widgets.


The project started from just a list of feature requirements needed to satisfy our early-adopting clients. I led the design, HTML, and CSS of the report editor and worked with multiple engineers on implementing individual parts of the tool.



Our goal was to rebuild Addepar’s existing desktop application report editor on the web, and to implement additional features improving critical parts of the user experience. We focused on the following main user flows:

  • Report creation for multiple clients
  • Use a client’s portfolio data in a report
  • Switch portfolio data within a report and instantly see a preview
  • Drop-and-drop tables, text boxes, shapes, images, and charts into any report
  • Use variables within text boxes
  • Use templated sections in multiple reports that sync if any individual section is changed
  • Have a header and footer library
  • Publish report to for a set of clients

The design of the report editor evolved over multiple iterations. Addepar’s skilled team of engineers has made it possible to develop ideas in code, and to adapt immediately to team and user feedback. I often sketch, prototype something in HTML and CSS, get feedback from fellow designers, and continue iterating. I would then collaborate with an engineer to integrate my designs into the application.

The iterative design and development process was only possible with high levels of trust between the engineers and designers, and a strong rational unattachment to the developed code. The detached perspective on previous investments was crucial in allowing us to freely design, develop, and improve the product without compromises.

I believe the final product reflects our highly iterative process. We learned a lot from seeing the interactions, testing them, and then iterating on them. Had we instead detached the mockup design process more strictly from code implementation, we would have seen less of a tight feedback loop. It has to be said that there needs to be a balance between iterating and planning. There are huge drawbacks when software engineers have to make changes to overarching software architecture midway. Furthermore, effective communication between engineers and designers, maintenance of team morale and energy levels, and respect for deadlines, all affect the final product outcome.




The project lasted approximately seven months, with the first version released in Q1 of 2014. The first web version of the report editor was a manifestation of the continuous efforts of amazing peers that incorporated responses to both team and user feedback.


The report editor is laid out into four main parts:

The navigation panel uses the OSX toolbar design pattern featuring the most important elements to the left, and the most heavily-used functionalities in the center. The two most important elements are the report name, and the currently-reflected client’s portfolio. Here, the user can switch between clients, which then dynamically updates the whole report with the given client’s portfolio data, including recalculations of portfolio performance graphs and other charts. This feature is crucial to advisors because they often prepare reports for multiple portfolios at once and switch between them to make sure the content and layout are correct. Widgets are easily accessible through dropdowns in the center of the navigation. Controls for the settings, publish, preview, save, and revert controls, are on the right.


An outline was added to account for the fact that the average report tends to be over 10 pages long. It allows the user to easily orient himself within a report, and to navigate to different pages by clicking on a particular page’s thumbnail, and define options on a section. Additionally, the outline also shows the different types of pages that exist. Overflow pages are generated by dynamically-sized tables and are shown by having lower opacity. At the bottom, the user can add additional pages to an existing section, new sections, or a linked section.


The inspector panel dynamically updates to display the element’s options according to the user's selection in the main editor area or in the outline container. A large number of options and controls were fit into the limited space of the inspector panel through the implementation of tabs and popovers. Unnecessary options are hidden from the user and displayed only when called upon.


A true WYSIWYG editor that holds the report and lets the user interact directly with individual elements in the report. It is particularly important to have an immediate preview of what the final report will appear like, because financial advisors care deeply about what exactly their clients will see. Additionally, we try to encourage good design standards by implementing grids that fade in when widgets are selected, and have widgets snap to it when they are resized or moved.



The report editor helps our users to save time and frustration. The following features were specifically tailored to our user’s work flows:

  • Widgets in the report editor are dynamic, and can be populated by any portfolio data through the context switcher in the top left. The table widget was especially difficult to implement, because it resizes vertically to accommodate portfolios of different size. In a collaborative effort alongside two brilliant fellow engineers, for which I was responsible for the HTML and CSS, we implemented a table widget that could render huge tables and still be resized, collapsed, and edited. Together, we also built one of the most advanced open-source text widgets supporting editable pills; we allow advisors to write messages and insert variables that dynamically update when the portfolio context is switched.

  • A linked section works similarly to Symbols in Sketch. It allows the user to implement a particular section simultaneously in multiple reports, which all sync if edited in the linked section editor. This saves immense amounts of time when, for example, the logo on the cover page needs to be replaced. While previously, any changes would need to be implemented separately for each report, the user can now make a change in a single report in the linked section editor, and have the changes be propagated to all the reports using that linked section.

  • Publishing reports is complex. Each report is published for a particular set of clients. Each of those clients can have a list of recipients (lawyers, accountants, and additional family members). The publishing modal in the report editor breaks the publishing process down into four simple steps:

    • Clients are selected for whom the report should be published to in the portal
    • Recipients for each selected client are chosen
    • Selected recipients are then determined to be notified or not
    • Summary page for final confirmation


We received positive initial feedback from our beta users and will be focusing on synthesising their requests as we release to more clients. The product roadmap includes more advanced features such as undo-redo and auto-saving, as well as further widgets that include transactions tables, advanced charts, and further text box options.

The communication design of the reports can still be improved immensely. We are considering providing templates and themes to our clients in the way that Squarespace does for their users. We are also in discussions on the extent to which advisors will have access to customization, and the level of responsibility we want to take for the design of the final report. Another issue is the practical need for paper reports, and when we can make interactive reports available. We are exploring that in initial phase of the portal.

The financial industry is in dire need for tools like these; I am proud that we were, as a team, able to contribute an effective solution to this difficult problem.