Zero-to-one, revamp construction software that gets funded and scale the team

One of the challenges for this project was trying to move from zero to one. We don’t have existing products, data points, or many competitors to learn from.

We use the opportunity assessment technique to identify viability risks and work on the monetisation strategy while creating the product and its brand.

Anility pivoted from procurement project to comprehensive construction software, encompassed from pre-construction to delivery of project.

We rebrand the company to reflect the new values and create new solutions to solve the old problems for the Australian construction industry. We designed Anility to help Australian construction companies reduce risk through data-driven decisions and insight captured directly from the construction field.

With a mission to improve the Australian construction industry, we have the vision to simplify the due diligence process. From mega to micro, Anility’s product will enclose from construction companies to individual subcontractors, from pre-construction to delivery of project.

Before we design anything, I’ve asked Partick (CEO/Client) to envision how people should feel about our product before (brand) and after (the UX) they experience it.

I gained a lot of insight and took on the concept of “Zoom-In for the details and Zoom-Out for the big picture” to mimic how we represent the data on Anility’s dashboard, where construction companies can Zoom-In to see the details of what’s going on with a subcontractor on a specific task or Zoom-Out to see all projects expenditure.

The pixelated “a” logo-mark will look and feel unique with its details when zoomed in to look closely. On the other hand, it will look like a typical “a” encapsulates the brand name and value in the big picture. To cut through the noise, I make our brand vibrant but contrasting, unique but familiar. I pay a lot of attention to OpenType features in typography, predominantly to the number figures.

As a V1 , we mixed a role-based persona (user’s role in the organisation) with a fictional persona (calculated assumptions) to define the user’s archetypes.

I gained the most insight from Patrick (ex-construction project manager) and do my own research from the internet to fill the knowledge gap.

There are three types of customers that we need to fulfil their needs include:

1. Project Owner:

• Who: Construction companies, client-side.
• Role: Ensure that expenditure and contractor performance are on the right track.
• Need: Make a profit margin

2. Principal Contractor:

• Who: A person conducting a business or undertaking (PCBU) that commissions construction work valued at $250,000 or more (source).
• Role: Identify and reduce risk on the construction site.
• Need: Deliver the project on program and budget

3. Subcontractor:

• Who: A person who the principal contractor hires to complete a specific task as part of the overall project.
• Role: Delivering high-quality outcomes and performance.
• Need: Improve tender success rate and win more work.

At initial strategy, we’re looking to monetise from the Project Owners/Principal Contractors (customers). Still, the software is powered by data captured by subcontractors (users), which can use our product at no cost.

We plan to add more features for users and charge a small project commission fee to turn them into customers, but it’s now out of scope.

In cases where the customer’s and user’s needs conflict, we will prioritise the customer’s needs because that’s the most important thing we can do for users.

Now we got the user stories from the Opportunity Assessment above, which is:

• As a Project Owner, I want to ensure that expenditure and contractor performance are on the right track so that I can make a profit margin.
• As a Principal Contractor, I want to identify and reduce risk on the construction site so I can deliver the project on program and budget.
• As a Subcontractor, I want to deliver high-quality work so that I can win more projects.
  

The story itself is pretty flat; there’s no context, just a prioritised list of user stories. How can we know one story fits in the big picture?

That’s what the CJM stand for; it gave a story context. I wrap up the CJM into three simple construction stages where all three user types work together.

1. Pre-construction stage: Project Owners or Principal Contractors create a project and invite Subcontractors to bid on the project. 
2. Tender stage: Principal Contractors or Subcontractors submitted documents and bid on the project.
3. Construction stage: Project Owners and Principal Contractors track progress and audit performance throughout the project. Subcontractors submitted the report and expenditure.
   

*Please note: The marketing journey map is out of scope.

Based on CJM above, I used the two-dimensional IA technique for this project. Major project activities are arrayed along the vertical dimension, ordered by the CJM from top to bottom.

The primary vertical navigation bar is ordered from the pre-construction stage at the top, the tender stage, and the construction stage at the bottom.

Along with the horizontal dimension, we nested progressive levels of detail based on the customer’s type and goals at a particular stage.

All the above means everyone sees the main navigation based on the construction stages, but information for each page will be based on their priority no matter what customer type they are.

As mentioned, we prioritised the customers flow as it’s the best thing we can do for the users.

We confront the feasibility challenge, such as a reliable connection to recall the API on the site, computing power to process the data, and so forth.

I have to design the dashboard as lightweight as possible but maintain all relevant contexts. I provide a customisable layout to suit people’s needs.

In the same features, Principal Contractors might use it on the site with the iPad where things tap (touch screen). While the Project Owner may use it in the office where things click (mouse cursor).

Of course, we must consider the internet connection and offline ability once we build the native app.

I use a modular design approach to create interchangeable design components and layouts for each feature and create a high-fidelity prototype along with the CJM as a go-to technique.

Patrick will take my prototype to validate with the customers (focus group), craft his pitch with the investors, and then come back to iterate the design.

We keep on this process and improvise once needed until we start gaining traction from customers, media, and venture capitalists.