Angl Works
ANGL was a construction management tool aimed at companies using the Building Information Modeling or BIM construction process. The idea was to merge Kanban style task management with construction management. After building the core BIM task manager, and acquiring some construction companies who were happy to beta test, we quickly morphed ANGL into a full business management tool, including chat, file and document management, with live document editing and meeting features, and a time management and budget allocation tool.
Construction Management With Less Digital Waste
ANGL promised web-based coordination for teams that build. Most mid-sized or larger construction companies have multiple projects going at one time, with shared personnel and resources on each job site. It's estimated that most projects lose 15-20% of their budget to waste. By creating a standardized tool that can be shared across internal teams, job sites, projects, and even companies, ANGL's goal was to turn wasted time and resources into profit.
To this end, ANGL began its life as a simple task manager with a BIM bent. Our main focus was on building a single page application using a Ruby on Rails backbone with Ember.js (though I always thought it was a shame we didn't choose Angular JS for the nice symmetry of naming). We chose Ember for our ability to create a hybrid web app with native iOS ability, and even an iWatch and Microsoft Exchange extension that could use core app features.
Building With Our Own Set of Tools
Once the main features of task and user assignment were functional we started using our own tool for managing development and design. It gave the team an intimate knowledge of the product we were creating, with all its pros and cons. We also had several construction companies using ANGL at this stage, allowing us first-hand user accounts from inside the industry we were targeting.
Moving Dirt Around the Page
I was handed a yellow-centric concept for a dashboard done on spec before my partners at the Agile League and I came on board for development. These early designs had bold yellow color, drop shadows, and hard gray boxes. Handling the design as well as front-end development, I quickly helped build a functional version of these early designs. As we used the app, the original designs were quickly muted, and simplified as much as possible, with the focus moving to displaying a few important details instead of a scattershot of task information.
We worked heavily on PSD to InVision for prototyping before moving a feature of update to the web application. As we added features, the design would evolve another step in order to streamline the information presented. Adding a chat feature for improved communication, then a document manager, and into a live document editor with voice conferencing and auto note meetings based on created tasks.
Once the task manager and chat features were complete, I knew there were other applications and features, so the focus moved to creating a simple framework of components that we could use between features. We broke the app into three universal sections:
- A universal navbar with search, settings, app switcher, and important screen sensitive controls.
- A sidebar with main app controls and navigation.
- The main document area, with an optional secondary right aligned sidebar.
This breakdown of dashboard components, which was further divided into sub components, helped manage the fast pace at which we were adding new products and features and kept a more consistent feel to the design process. It also helped mitigate the constant push to rework and redesign the functional app, something that had been done four times since launching in beta.
A Higher Focus
After working on collaborative document management and meeting features, we moved into a 10,000 feet-esque budget management tool. The idea was to help assign tasks based on workload and get the higher view of budget on a project by project basis. If we could tie an application such as 10,000 feet to an application like Trello, and have the two inform each other, a manager could better assign tasks to reduce overhead.
A Build Left Unfinished
ANGL never grew beyond that initial group of beta testers. Feedback was positive and users seemed genuinely intrigued by the usefulness of the application. This was my first experience with a failed startup. I believe the idea was sound, and have even recently lost a talented designer hire to a startup doing the exact thing ANGL was attempting, six years after its failure.
For my part, I believe we had mismanaged our product meetings. We were so focused on building the next feature or completely reworking the flow of current features, that we neglected the sales aspect and didn’t iterate features in a business conscious way. Our decisions weren’t based on improving the bottom line or honing our core task manager to be the ultimate tool that our construction-based users need, instead we kept adding and adding secondary products.
In my current position at THIRDHOME, we base all big ticket tasks on a product team with multiple voices, a COO to voice business concerns, a CTO and Director of Development to voice tech concerns, and myself running UI/UX to give voice to users. With ANGL, the CEO came to us energetic with a new idea and we’d thrown ourselves into building without setting metrics for success or seeing if our newest feature had time to get traction.
Going forward, setting up a Product Team that helps craft the application with multiple voices, viewpoints, and well-defined testing and metrics for success, is the way we insist on building.