EXODUS - Property Acquisition App
Objective: (12 Week UX UI Programme) To build an app which serves and solves the frustrations of the property industry and the problem space of administrative demands.
Role: To brand and prototype lo-fi screens, storyboard and deliver a working prototype proof of concept. Using class critiques and mentoring.
Outcomes: Hi-fidelity Mock-ups. Design for proof of concept prototype.
Use Cases for MVP:
1. Open lines of communication across the buying chain.
2. Smooth document handover, from paper and fragmented storage facilities to digital.
3. Remove the overload of choices and price variation for legal and administrative support.
Features:
1. Full visibility and the capability to chase the other parties along the chain.
2. Content housing and hint and tips as to what document you may need next.
3. Based on the user details and stage in the process, suggestions will be made as to who the best support will be.
Define
At the define stage we needed to start taking the results from the survey and collating it down into some manageable user profiles, and mapping their frustrations along the home ownership journey.
Approach:
Delivery
At this point in the project I started to focus on the UI, after having various rounds of feedback from colleagues and mentors I started to develop the branding, and prototying my application.
It was at this stage I developed the design system and checked it for accessibility.
Outcome:
1. Reduces frustrations during the waiting period, and adds pressure to slow parties.
2. Efficient and streamlined working practices, due to full information in one place.
3. Reduces the mental load, while trying to move house and consider best value for money when it comes to administrative process and support.
Discovery
To buy a house, or in fact any change of address whether buying, selling or renting is a faff, not just “oh i forgot my bag for life at the supermarket” faff, but a pain. Which we have all come to accept for some obscure way. However our discovery took us to understanding some of the specific pain points and intricacies of the process and discovering some solutions.
Approach:
Develop
The next stage of development started to consider how each feature would be presented using lo-fidelity wireframes, this would allow for fast progressive design while not being caught up in the details. At this stage I also looked for inspiration on how other designers had presented similar features, utilising Jakobs law, where users will be able to use your product easier if it is something they have already been made familiar with in other products.
Approach:
Persona mapping allowed me to build out a wholistic picture of the potential user into the workshops and activities, and start to match client needs with industry problems and find solutions for each.
Empathy mapping was a great tool to provide clear distinctions of where the frustrations were coming from and when, this provided a clear map for potential solutions for when certain actions were taken, how they could be enhanced, inproved or removed by digitalisation. e.g. mailing documents compared to uploading them.
Card sorting is a great activity to group pain points in groups of a similar category, this helps streamline the process of deciding on which feature to build, if there is correlations and multiple of the same pain points, this may well be worth focussing on first. It starts to make the the user fratrations more manageable by finding patterns within behaviours.
Feature prioritisation brings in the needs of the business, as it may not be viable to build solutions and features for all the pain points. Mapping the pain points to business ability and vale is a good way to make sure time in devlopment is being used effectively and efficiently.
Feature mapping makes the features align in a logcial thought flow, which in turn starts the basis for the wireframes, as now I knew what to design and when.
