Management Quality Consulting

Podium Data was a start-up company, founded by a group of data experts from MIT. Podium’s product was a web application for managing “Data Lakes,” and it had the ability to import and update data from a myriad of different types of data sources that a company might have, and do so with unprecedented speed.

Podium’s APIs and back-end were the core of the product, and the UI had its origins as a time-boxed 2-month project, handed 3 years prior to an outsourced consulting outfit made up of primarily Java developers. For the past 3 years, additional features and UI enhancements had been built on the foundation of this 2-month project, and it showed.

A good UI is both A) Functionally Intuitive, and B) Visually Attractive.

The Podium UI that I inherited was neither.

• It lacked usability, cohesiveness, and good standard UI practices, and was visually dated and unattractive as well.
• Most of the UI was made up of a series of “grid” pages that described the “metadata” of data sources, tables, and fields. It was informative at a detail level, but no more intuitive than a “stack of spreadsheets,” and navigation was difficult.
• There were a lot of inconsistencies in how information was presented on the site. For example, in some areas, detail information was presented in a “side-panel” wizard, and in other areas similar information was accessed via a “modal” pop-up dialog.
• There were portions of the UI where important information was hard to find, or obscured by error messages if a user made one wrong click. The CTO would refer to these as “brain-dead issues.”

I had been hired by the Director of Engineering to identify the issues and priorities of the existing UI, including both the code base and the UX, and then formulate and execute a plan to address them. Also, there were 2 UI developers in the outsourced consulting company who I would eventually manage in the capacity of team leader.

My first order of business was to interview each of 3 “stakeholders” who had been identified to me as having the most knowledge of the problems in the existing Podium UI. They were the CTO, Product Manager, and a Pre-Sales Manager. I had a 1-2 hour session with each of the three, after which I consolidated my notes onto a whiteboard, where I listed 1) the top 3 UI priorities according to each one, and 2) other improvements that were “like to haves.”

The combined feedback for the “Top 3 Priorities” was captured and combined on this initial whiteboard:

From the intersection of the lists, I was able to identify the top priorities, as well as some secondary and tertiary ones.

I also met with the Director of Engineering, to go over the current UI feature requests and “major bugs” in the bug reporting system (in a web-based system called Assembla). Finally, I got priority feedback from the Director of Customer Success to get his input on priorities based on existing customer feedback. I combined the Assembla bug database reports with the “Top 3” priorities of each of the management stakeholders, and synthesized it into the following spreadsheet:

• Master Spreadsheet of UI Priorities

In parallel, on the technical side, I got access to the UI code base, which was written in AngularJS, HTML5, CSS3, and core Javascript. I began familiarizing myself with this as well, and began a dialog with the Software Architect to find out what the strategic goals were for the code base, both present and future.

There had been an effort started (also outsourced to the consulting company) to port the AngularJS UI code base to Angular2. This effort had gone on for about 5 months by one developer in a silo (who had recently left the company), was portrayed as about 40% done, and had stalled. As UI Architect, I needed to also assess the state of this effort, as well as its relevance to the current code base, and come up with the best path forward overall.

The highest priorities fell where the stakeholder feedback AND bug report/feature tracking overlapped:

• Standardize on Modal Dialogs for all multi-step "wizard"-type functionlity.
• Improve existing modals (add tabbing, make buttons consistent)
• Convert any "side-panel" wizards to Modals, removing issues like redundant scroll bars and duplicate left "<"" and right ">" arrows that were needed to open and close the side-panels.
• The primary side-panel wizard to be converted to a Modal was the "Source" Wizard, used for creating and modifying data sources.
• The overall style, including color scheme, button styles, and other CSS UI elements, needed to be improved.

In addition, the project to port the code base from AngularJS to Angular2 would be put on hold, pending further business and technical analysis.