Defining requirements and identifying functional gaps

Have you heard of "Blockchain"? Maybe not, it's pretty obscure. Anyway, if you have heard the whispers you'll understand this concept. In UK real estate, a Chain is a sequence of linked house purchases that revolve around key dates, a plethora of paperwork and many back and forths between each agency's Sales Progressor. A sale, or 'link', that is managed by a Rex user is referred to as a ‘Branch Offer’.
This process doesn't exist in Australia and thus neither did the functionality in Rex. During our early discovery this was flagged and investigated in some early user research sessions.
From them, we divined the following high level user needs:
  • Create, edit and archive a Chain
  • Track progress of individual Links and the Chain as a whole
  • Easily access contact information for the solicitors and agents for each link
  • Record the details of an offer and track its status
  • Decrease or increase an offer and communicate this to the seller
understanding the problem

Chains for dummies

Each of the 'Links' or property sales above must go through ('Exchange' and 'Complete' on the same day. This means a lot of communication and tracking of 'Milestones' (e.g. mortgage approvals, building inspections, finance etc.) by the Sales Progressor
Early concepts

Square peg, round hole: the wrangling of a legacy design system

My colleague began reviewing our early interviews and competitor research to create user personas and wireframes using the app's existing design system.
Early wireframes: Link information and easy access to contact cards
Early wireframes: visualising a Chain
Early wireframe of an Offer in a 'primary' layout.
After a few rounds of wires, there were still several gaps in the required functionality of the designs and hesitation from the team about the use of legacy patterns vs. new ones.
While my colleague moved on to another project, I took over pattern exploration and met with our leads to tease out limitations for introducing novel UI. I presented on the below options (and more) and we defined constraints to move us forward.
We settled on the faithful side given our tight deadline, already bloated design system and limited dev resource. The main outcome of this was modals, lots of modals.
Exploration: Larger Offer Modal with Tasks,
Exploration: Chain modal
Exploration: Full screen chain
Validation & testing

The devil is in the detail...and he will kill you (or your feature)

Once we had a solid footing on UI constraints, I needed to dive deeper on the workflows that had been missed in initial concepts.
  • Are notes and progress tracked agains Chains, Links or both? (This would effect where the user could view and action them)
  • Have we comprehensively covered the fields required for data capture on offers?
  • Who are the most contacted people for each link?
  • Can a user successfully use 'Milestones', do these meet all the tracking requirements currently being captured on paper?
  • How often do Split Chains occur and how many splits (before a wild tree is formed) do we need to accommodate?
I went to our users for (some) of the answers, interviewing 5 agents and running them through 4 prototypes.
Results of the testing pushed us forward in functionality and gave us a nudge on UI. Surprisingly the modal interaction was a hit and our anxiety about having compromised on it was slightly assuaged.
I also garnered some great terminology insights to make the actions more intuitive for users and add in helpful status markers such as 'Completing a Chain', 'Marking End of a Chain' and so on.

A smarter, more transparent way to keep track of property sales

The final Offers & Chains feature-set was rigorously researched, documented and tested, resulting in a smooth implementation and reception from users. The compromise made on top shelf UX patterns in order to be faithful to the design system meant a lot of iterative back and forth and creative thinking to maintain a great user experience using limited screen real estate.
Tasks and activity on offers and chains were excluded from the first release due to their far-reaching impact on other parts of the app, however the addition of a status marker and customisable Milestones gave users easy oversight of progress on their Chains. Below are some of key user workflows from over 20 that we implemented.
Recording and offer increase and viewing history
A Split Chain
Adding a link to a Chain
Completing and adding Milestones

Assumptions and skipping parts of the process chains your brain

I learnt some good process lessons with this one. Firstly, never assume the contents of another designer's Sketch file is approved or thoroughly researched. I rushed into designing under time-pressure and it tripped me up more than once on this project in reviews. From now on, I make a point of spending as much time necessary reviewing the subject matter and brief before beginning.
In this vein, I should have pushed for more well-defined phases of design and review.  Seeing a chunky piece of functionality through from beginning to end (and using a large, untamed design system), can start to take a toll on creativity and attention to detail without milestones to aim for and look back on.