Using object-oriented UX to define and design a digital auctions system
- 2022
- Freelance
The context
I designed a digital auction system which allows city halls to sell various goods to citizens, such as commercial spaces, used tech equipment or abandoned cars.
I received a project brief which painted the high-level picture of the product, in terms of user roles, tech stack and legal requirements that needed to be followed. During the design process, I clarified the details of how the system should work, idetified all possible states for auctions and lots, and designed the user flows for both city hall officers and bidders.
Role and process
For this project, I worked as a freelance UX designer/consultant for a development company that specializes in creating digital products for local administration institutions.
I collaborated with the development team and city hall stakeholders through weekly meetings in which we clarified project requirements and gathered their feedback.
Between research and design, I used Object-Oriented UX to define the structure of the auction system.
The initial discovery sessions with the stakeholders helped me clarify the project brief. To gain a deeper understanding of the users and processes, I did user interviews and used online resources such as forums and studies. I used Object-Oriented UX to define the structure, architecture, flows and interactions. From there, I created wireframes to gather feedback and ultimately develop the final UI.
But first, what is OOUX
Object-Oriented UX (OOUX) is a design philosophy developed and evangelized by Sophia Prater.
This approach is based on the idea that people's mental models are rooted in real-world objects. So, when designing digital systems and products, designers should break down complexity using objects (nouns), rather than actions (features, user stories, task flows), to better align with users' mental models. More, OOUX helps align design and development, since developers also work object-orientedly. According to Sophia, OOUX sits in the center of the double diamond model, serving as an aid between reseqarch and design and a way to simplify system complexity in terms of information architecture, flows, and interactions.
You can read more about OOUX on Sophia's website
While OOUX is a philosophy and its guiding principles, ORCA is the hands-on process behind it.
The four pillars of ORCA are:
- Objects: real world things that bring value to the user and to the business;
- Relationships: ways objects relate to each other;
- Call-to-actions: affordances of objects;
- Attributes: the structure of objects (core content and metadata).
For example, on Instagram some objects are users, posts, stories, reels, comments, products. In terms of relationships, a user has many posts they create, and a post has many comments. A post calls a user to like, share, comment, bookmark (call-to-actions). And finally, a post has images, caption, timestamp, number of likes and so on (attributes).
The ORCA process consists of 4 iterative rounds. Each round focuses on the four pillars, and each iteration builds on fidelity.
The challenge
Design a complex auction system which enables city halls to sell goods to citizens.
Discovery revealed a complex system with three user roles (admin, logged in user and visitor), multiple states for each auction, and a complex flows: there were multiple auctions running simultaneously, with several lots in each auction and many people placing multiple bids on different objects from the auction.
Why I chose OOUX for this project
With a tight timeline of less than a month and limited after-hours availability (since this was a side project), I needed a methodology that could help me manage the complexity efficiently.
By using OOUX, I was able to break down the complexity of the system into manageable objects and had fun while trying something new to expand my skillset.
The result
An easy auction system for both city hall employees and citizens.
City hall officers can easily create and manage auctions, while having complete traceability over each auction and lot. Bidders can quickly bid on their desired lots and watch competing offers real-time.
For citizens
Making the process easy to understand and follow, for both first time and experienced bidders.
The initial research revealed that many people are hesitant to participate in auctions due to a lack of trust and understanding of the legal procedures involved. To address these concerns, I created pages that clearly explained the auction process using simple terminology gathered from the research.
Bidding on desired lots and watching auctions real-time
Citizens can bid on desired lots and monitor their offers in real time. With notifications, they can stay informed if their offer is outbid by other bidders.
Keeping track of current, past and future auctions
The "My auctions” section keeps track of current, past and future auctions. In the current auctions, bidders can have an overview of active auctions and quickly place bids on the lots they are following.
For city hall officers
Enabling city hall officers to easily create and manage auctions
The admin interface allows users to create, edit, publish and unpublish auctions. If a lot remains unsold in an auction, admins can easily duplicate it and add it to a new auction, saving them time and effort.
Verifying potential bidders and bids, in order to comply with local rules and regulations
To follow legal procedures for public auctions, city hall officers must verify that bidders comply with the rules and reject those who don’t. The admin interface makes it easy for officers to reject non-compliant bidders and provide a reason for the rejection. The system then notifies the bidder of the rejection and the reason.
Enabling traceability of auctions and lots
City hall officers are responsible to keep track of what happens to each lot in an auction. This can be a difficult task, since sometimes various corner cases can appear. For example, once an auction closes, admins are required to verify the winning bidder via phone call and set a date and time for pickup. But if the person doesn't pick up their lot, admins have to contact the next highest bidder and redo the process. To optimize this task, the interface easily allows admins to keep track of winning bidders, providing traceability for won lots.
Getting there: research
To familiarize myself with the terminology and processes, I started the project with an initial research phase.
I collaborated closely with the stakeholders, clarifying the project brief and raising important questions. I used online resources to gain a deeper understanding of how auctions work.
Online research
I conducted research online by examining similar systems and reviewed forums, articles, and research papers
Analyzing similar online auction systems, I gained an understanding of the main user flows and identified essential features, some of which were also mentioned in the project brief. Forums and research papers highlighted potential concerns and needs, such as a lack of understanding of the auction process and fears of being cheated or taking risks.
User interviews
I also held remote interviews with two city hall officers who had been previously engaged in on-site auctions. This revealed insights about their process and pain points, as well as potential participants.
Key points from user interviews:
- a lot of responsabilities for officers, such as verifying each participant's registration, contacting and verifying winning bidders, keeping history of won and not-won lots;
- sessions are often very short, around 15 minutes;
- officers face a lot of pressure, since this auctions are public and covered by local media;
- participants are either individuals or small companies, mostly men.
“Whenever we hold an auction, there is a lot of pressure because there are many participants and a lot of papers and documents to check. The auctions are public, local newspapers often write about them. We had a case when the city hall officer announced a wrong winner because she had mistaken the files. The press discovered and accused the city hall of fraud.”
Putting it together
Based on the brief and the knowledge gained, I put together proto-personas and a high level structure of the website.
The content frames helped paint the general image of the system, but most of the system's functionalities actually resided in the various object states and flows between these states. These we accounted for during the ORCA process.
Getting closer: ORCA
My initial research provided me with a good understanding of the users (potential bidders and admins), as well as insight into how the bidding process should work. Then, to bring structure to the process, flows, and interactions, I used the ORCA process.
Over 4 iterative rounds, I focused on exploring potential objects, actions, attributes, and relationships. Then I translated these into structured components, pages and navigation flows.
ORCA round 1 - discovery
I did noun foraging and prioritized between what could be a core object and was merely supporting data.
During my initial research, I kept an eye open for important nouns I came across in the brief, in forums, articles and research papers. I ended up with a huge collection of nouns. In several iterations, I downgraded anything that could be supporting data, or data that describes an object, rather than being a top-level “primary” object itself, and grouped similar terms for the same object together. I ended up with 4 core objects: AUCTION, LOT, BIDDER and OFFER.
After identifying my four core objects, I used the insights gained from my research to define their relationships. I then mapped out each object's actions and brainstormed all the attributes that could be associated with them.
While I found relationships easy to define (for example: An auction has 1 to many lots in it. A lot can belong to 0-1 auctions), CTA discovery was a bit trickier, since there were three user roles involved (admin, signed-in user and visitor), each role having different permissions, thus different CTA's. I put them all together in a CTA matrix and the attributes in an object map.
ORCA round 2 - requirements
In the second round, I built upon the discoveries from the first one and created an object guide that detailed the core objects. This guide was useful in defining the overall structure of each component and page, and also brought up some interesting questions.
In Sophia’s words, an object guide is a “glossary on steroids”. It defines the core object with potential instances and labels, user and business value, main lists, content strategy and more.
For example - an “auction” is a collection of “lots”, defined by a start and end date for registration and bidding, a set of rules for bidding and a participation fee. Potential labels would be auction, auction session, procedure. In terms of purpose, it enables the admin user to define a single set of rules for multiple lots, it allows the bidder to bid on multiple lots with just one participation fee, and, in the system, it groups nested objects together. An auction can be part of many lists, such as “active auctions”, “my past auctions” and so on. Defining the content strategy revealed a lot of questions regarding how the system works, for example: Are expired instances archived automatically? Can archived auctions be deleted? Should auctions or lots be created first? If a lot is not sold in an auction, can it be moved to another auction, or does it have to be created all over again?
Building onto the CTA matrix, I developed object-oriented user stories, which refined the functionalities and helped the development team later on.
An object-oriented user story is, well, a regular user story (As a <role> I want to <action> so that <result>) with a twist - it focuses on the object rather than the action: As a <role>, I want to <action><object> so that <result>.
For example, “As a city hall officer, I want to edit (CTA) an auction (object), so that I can correct any mistakes I've done or add new information (result).”; “As a bidder, I want to be informed of any changes on an auction, so that I can decide if I still want to participate or not.”
ORCA round 3 - prioritization
During the third round, I prioritized the core objects, their relationships, CTAs, and attributes, resulting in an updated object map, which later informed the sketches and wireframes.
Each object had a multitude of relationships and attributes, so prioritizing them was a matter of force-ranking based on the understanding I had gained during research, of user needs, pain points and competition. It was so exciting to see how this updated object map later informed the sketches and wireframes.
ORCA round 4 - reprezentation
In round 4, I transformed the artefacts from the first three rounds in cards, lists, pages and components. I linked all pages together in nav flows, which revealed possible interactions and local navigation.
This round consisted of doing ORCA style sketches, directly informed by the prioritized object map. The single-column design of the ORCA sketches allowed me to focus on prioritization and hierarchy, as opposed to spending time on layout and UI details. I linked the sketches together in navigation flows, focusing on the interactions between elements.
In a demo and feedback meeting, I presented and discussed these flows with both the development team and city hall stakeholders.
The main feedback I received was that the sketches didn't account for some special situations and edge cases, such as removing an uncompliant bidder from an auction, or sending motive for rejected bidders. There were also some legal requirements that I hadn't accounted for. For example, when unpublishing an auction, the city hall is legally required to inform registered bidders about the reason. To cover all these cases, I did a second iteration of the sketches and nav flows. You can see both iterations in the Miro board below.
Challenges
The representation round was definitely the most time-consuming, as I had to deal with complex flows and multiple states for each component. However, tackling this complexity in the early stages with low-fidelity designs saved a lot of time later on.
The biggest challenge I faced in this project was managing the various object states and flows. For example, an "auction" has both internal states (published/unpublished/draft) and external states (registration announced, registration open, registration closed, auction open, auction closed). Similarly, a "lot" inherits these states from its parent "auction". Moreover, a "lot" can have different states for different users, depending on whether they have placed a bid on the lot or not, or if their bid was the highest or exceeded by others.
The ORCA process was vital in helping me uncover and deal with the complexity of the project in the early stages, which brought clarity to the flows, interactions, and overall user experience.
From ORCA to Interaction Design
With the ORCA sketches and flows finished and approved by the team, I moved on to interaction design.
Having everything mapped out in a structured way, it was easy to further refine the sketches in higher fidelity screens and more detailed interactions.
From Nav flows to user flows
I refined the ORCA nav flows in user flows, which revealed various edge cases and unhappy flows. By gaining an understanding of all these cases at an early stage, I was able to address them in a consistent manner.
For instance, a city hall officer (admin user) can make edits on a previously published auction, even if bidders have already registered. However, if such edits are made, the bidders must be notified (As a bidder, I want to be informed of any changes on an auction, so that I can decide if I still want to participate or not). Moreover, admins must manually review each bidder's registration for an auction and approve or reject them if their registration doesn't meet the requirements. Additionally, if a winner doesn't collect their prize, the admin user must manually revoke their winner status and inform the next highest bidder. Having an understanding of all these edge cases allowed me to handle them consistently during the design phase.
From sketches to wireframes
Going into higher fidelity, I designed wireframes for all screens, which were directly informed by the initial sketches.
Doing the ORCA process gave me complete clarity over what each object and page looks, hierarchy and possible interactions. I designed wireframes for all screens and linked them together in a prototype. I then used the prototype to get feedback from stakeholders.
Feedback and iterations
Of course, there were specific interactions that had to be accounted for in several iterations. In a feedback session with city hall officers, they expressed their concerns regarding having to add multiple lots at a time.
Initially, in the "add lots to auction" flow, each new lot would be added as a separate card, allowing for a lot of information to be added and easily previewed. However, during a feedback session with city hall employees, they mentioned that most lots would only have a short description, and their main need was to quickly verify all lots at a glance before publishing the auction. To accommodate this need, I changed the card layout into a table layout, while still keeping the option for each lot to be viewed as a separate page.
From wireframes to design
With the wireframes agreed on, I moved on to final UI design, defining the styles, components and finally, designing pages.
I built the final designs based on the wireframes, incorporating brand colors and styling components. I also created mobile versions of the screens to ensure a consistent user experience across different devices.
Learnings and outcomes
The MVP received excellent feedback from the stakeholders and they were amazed by the process we had undertaken.
During the process, they were surprised to discover the level of complexity that hadn't been accounted for in the initial brief.
I managed to deliver in time and helped reduce workload for developers.
The development team found the object-oriented user stories that I delivered to be particularly helpful in planning their workload. By using an object-oriented approach, I managed to better align design and development and improve efficiency.
I had so much fun trying a new method and expanding my skillset.
Exploring and implementing the object-oriented UX approach was a refreshing and exciting experience that expanded my skillset as a UX designer. The positive feedback I received, as well as the clarity it brought during the process, made me feel confident in the value of this methodology.
