Project Brief
Query was a product aimed at the construction industry. Our goal was to provide a software solution that changed how architects, structural engineers, inspectors and other industry professionals certified projects and used regulations.
While our product never ended up seeing a commercial release, we eventually decided to release what we had built for free.
My role
Primary Responsibilities
My primary focus was app design and research. This included everything from running design exercises with the team, iterating on our UI as we went from wireframes to hi-fidelity mockups as well as doing research and testing our work with users. These responsibilities took up about 2/3 of my time and are the components of our product I was responsible for end-to-end.
Secondary Responsibilities
These were the responsibilities that took up the other 1/3 of my time. Examples here include supporting other team members by
- Incorporating questions into user surveys that would help drive some of our business decisions.
- Making sure we have a unified brand across all our communications
- Taking on some of the frontend work such as building our landing page and refining the UI implementation myself.
The problem we were trying to solve
The core idea for Query was simple: Make regulations easy.
Inspiration struck when one of my friends, an architect turned land developer brought up how much of a pain it was thumbing through the Ontario Building Code (a 400+ page set of binders), when trying to validate whether a set of blueprints, measurements or proposals were up to code.
I wish I could just type in what I’m looking for, and get all the relevant sections and paragraphs, instead of me having to flip back and forth, going from table of contents, to section, to references, to other sections hoping that I’ve covered everything.
The Ontario Building Code, (and as it turns out a large number of other government regulations) are still stuck in the proverbial dark ages. They’re only available from the government as a hard copy, a raw dump of the text, or some third parties offering poorly constructed PDF versions.
The process to certify a project can be convoluted and downright headache inducing. Pouring through plans with the code in hand takes time, which costs money. Missed errors and instances of non-compliance could result in fines or potentially expensive fixes at best (which again cost even more money)… or something failing and someone getting hurt at worst.
Our Solution
We aimed to digitize the code, index it and make it searchable. Search results would be listed in the main view as well as highlighted in the table of contents.
Embedded references to other sections would be highlighted within the content or surfaced in dedicated part of the UI and users could jump to referenced sections with a single click.
If our proof of concept worked, the same framework could be adapted to any standardized body of regulations in any market, from food safety to automotive or aerospace engineering.
Research
We started our product development process with research. We looked for and analyzed direct and indirect competitors to determine market saturation and any additional markets we could expand into.
Surprisingly, the market was fairly unsaturated. None the less, we identified a few key competitors and did a basic SWOT analysis for each to make sure we had a shared understanding of the product landscape. Coupled with our patent research and insights gathered from initial user interviews to gauge interest, this research formed the basis of our plan for execution.
Design
I’m a strong believer of the idea that design can be a key market differentiator, especially for a startup. First impressions count for a lot, no matter what industry you’re in. Nailing the core product experience, surfacing a polished UI and a clear brand aesthetic helps inherently build trust. It shows a level of dedication and expertise that is immediately recognizable to all your customers regardless of their technical background. Paying attention to the details is your first and clearest indicator of quality, and if people get the sense that you’ve invested in yourself and your product, they’re more likely to trust and invest their time (or money) as well.
Brand development and a visual design language
And that first impression often starts with having a strong brand identity and aesthetic.
To that end, I worked with the team to design a logo and brand, which would also form the basis of the app’s visual language. This work also included a website / blog, shirts, business cards and other collaterals. Things which would come to serve us well when we decided to approach industry contacts for user testing or tried to make new connections at trade shows etc…
Persona
Based initially off of aforementioned friend (and co-founder), our primary persona was Kevin — a young, tech savvy Architect who who was struggling with the archaic tools and processes of his trade.
We had the benefit of having an industry expert on our team, which went a long ways towards helping us understand our users and their frustrations.
We continued to refine this persona as we conducted user tests and further research but the core vision of who we were building this for was always very solid.
UX Design
Though we didn’t have a clear or well defined process at the time, our research and the subsequent development of our persona drove what the core experiences of our MVP would be, and where we’d aim to take the product in future iterations.
But to help get our head around how this thing would take shape, we started by mapping out the information architecture and some basic user task flows. This work then lead into the design of some basic wireframes which helped us start to get a sense of what these user journeys would be like in action.
UI Design
Doing these types of lofi, clickable prototypes helped us both refine the previous IA and start to hammer out the basic UI architecture. As we moved through to higher fidelity designs the interface continued to evolve. Things that work well in sketches and wireframes don’t always translate well to more high fidelity work and this was no different.
Details like the placement of the branding and the search field seemed fine in our wireframe, but the waste of space became obvious as soon as we moved to Sketch.
The key was to remain agile and work in tandem with development. While I was working on the design, our 2 devs were setting up our stack, and refining the script that would parse the OBC into a format we could consume.
Home page and Product Frontend Development
By the time frontend work on the app was starting, the product’s design was in a good place. Not finished, but far enough for development to start. So I switched gears and began work on our team’s landing page and product blog.
Outside of the initial backend setup and the occasional JS tweak and CSS wizardry help from Philip (our main engineer), the design and development of our home page was my responsibility.
While I was doing that, it didn’t take long for the product’s UI to start coming along as well and it wasn’t long before I switched gears back to product work. Working on evenings and weekends, in a few weeks worth of time we went from those early wireframes, to a basic and unstyled but functional UI, to a mostly polished product.
We adopted a pretty loose version of Agile. We skipped processes and rituals like retros and regular standups etc… but following the basic principles of Agile development and design by planning together, working in short bursts, reviewing our progress at regular intervals and refocusing on priorities as required, allowed us to work quickly and make efficient use of the limited time we had.
Validation
Once we had something actually useable, we got in touch with a few of our contacts to do some validation. The long and short of it is, as far as what we had built was concerned, having an industry expert on our team to provide constant feedback and insight during our design and development had paid huge dividends. People were impressed, immediately saw the value of what we were trying to do, and had little to no trouble navigating the UI.
But one thing that became clear fairly early on is that to monetize this idea, offering the OBC wasn’t enough — we had to be able to offer the full breadth of regulations related to the construction industry, from fire codes to zoning bylaws, agricultural building codes, to supporting volumes of the OBC etc…
Ultimately this is where we failed. While we were able to arrange to have the rights to redistribute the OBC through our app, we ran into legal roadblocks when attempting to also acquire and include additional regulations. Roadblocks that we didn’t have the time or the resources to adequately tackle so we decided to sunset the project, shook hands, took the lessons learned and continued on with our respective careers.
Reflection
Looking back, things like the market research got us off to a good start, but we had a lot of blind spots in terms of business development. We always intended to offer multiple regulatory texts as part of our platform, but we didn’t anticipate that this was a requirement to us being profitable, rather than an enhancement we could offer down the line. By the time we decided to pursue acquiring these regulations in earnest, we were already into development, and by the time we hit a wall, we already had a working prototype.
A few years older and hopefully wiser, with a few more releases under my belt, there are a number of things I’d do differently today. Being more involved with business development is one of them. Designers often struggle with getting buy-in for doing “Design Thinking” sessions with other stakeholders, but the commercial validation we did once we had “designs” and a prototype could’ve just as easily been done with:
- An empathy map to help us align around a proto-persona
- Needs statements or Hills
- Some as-is and to-be scenario maps to work through user journey(s), driven by the needs statements and hills
- At most a basic IA and some sketches or wireframes to help give form to our solution
While it wouldn’t necessarily have been enough to sell the idea or to forge business relationships on, it would’ve been enough to do some of the business validation and help us better prioritize where we focused our time and energy from the outset.
Pivot
Philip and I eventually circled back to the project. We figured we were about 90% done and we didn’t want to see our work go to waste. That being said, implementing the first 90% of any project tends to account for 90% of development time. The last 10% tends to account for the other 90% of development time. With that in mind, we looked at what we needed to do to get Query up online and available to demo — without spending the next 6 month’s worth of weekends on finishing up development.
We focused on wrapping up loose ends and streamlining the existing core features and experiences by:
- Stripping out now redundant features like account management and summary pages.
- Simplifying and moving features like bookmarking and navigation history
- Refining the core search experience.
If a picture is worth a 1000 words, than I think a demo, even 90% complete is worth a 1000 pictures — if you’re curious about the work we’ve done up till now, you can check out Query at http://query.base5.com/
