Using OOUX to Lay a Solid Foundation During Discovery

Creating a gig-economy for anglers to share fishing tips


Two entrepreneurs, who were also avid fishermen, saw a need to build an app for anglers to buy and sell their local, up-to-the-minute fishing tips. They had a business plan in place and wanted to gather requirements to get an estimate for design and development and create a proof-of-concept prototype to show investors.

The Challenge

The challenge was to connect fishermen to knowledgeable anglers in the area to exchange tips for compensation.

My Role

I was the lead UX Designer, where I facilitated the workshops, created deliverables, and led the communication with the client and team throughout the process. The discovery included 6 workshops, Object-Oriented UX deliverables, user-flows, proof-of-concept wireframes, a prototype, a product requirements document, an estimate for design and development, + some coffee + some fun.

Mobile App Prototype
2 months
Workshops, OOUX/IA, Wireframing, Prototyping, PRD

The Problem

Fishing guides and fishers who own shops feel like they have to give information away, and they don't have a way to charge for their hard-earned knowledge. Questions like, "Where are the fish biting this time of day?" or "What is the best rig to use in these conditions?" are common. At the same time, Anglers feel bad when they ask knowledgeable anglers for tips without compensating. There is no large-scale online gig-economy for anglers to help solve these problems.

Fishing Guides say:

"I get 10 phone calls a day where people ask me for the best spots, I can't charge for this."

Anglers say: 

"I feel bad when I reach out to ask for a Tip + I wish there was an easier way to get solid Tips."

Workshop Prep

Breaking apart client documentation

Workshops with the client were on the horizon, so I started prepping by combing through their documentation, looking for the following:

  • Objects (blue): Objects are the system's main parts that have relationships to other parts of the system. As you can see below, Anglers and Tips are highlighted multiple times, which means they are major players. Other objects emerged, such as Reviews, Posts, Stories, and Transactions. Just by doing this, I already have a great sense of the system.
  • Attributes (red): As I'm reading, I also highlight metadata and content. This helps me understand what each object is made of and will be helpful when building an Object Map. For example, I can tell from the first sentence that species, locations, techniques, and skill levels are attributes of an Angler and could be attributes of a Tip.
  • Calls to Action (green): Thinking through the actions helps me understand what people can do in the system. I see that Anglers can Buy, Sell, and Trade Tips and that Anglers need the ability to "Speak to a Seller."
  • Roles (purple): I also highlight other important info in purple, such as the Buyer and Seller roles.
Client documentation w/ OOUX highlighted

Instead of just reading the documentation, I have a structured way to break apart and understand the system. It's interesting to see how quickly you can pick up information.

Creating OOUX Deliverables

Using all of the documentation from the client, I created a Relationship Map. This usually takes an hour or so, and ensures that I'm prepared, highlights critical questions and concepts to explore, and makes a clear structure in my mind for the workshop. During the workshops, I re-create some of the deliverables with the client using a white-boarding tool, but I like thinking it through in advance if possible. What's the saying? - "Give me six hours to chop down a tree, and I will spend the first four sharpening the ax."

Let's dive into the process. First, I list the objects:

Next, I start thinking through their relationships by creating a System Model / Relationship Map. For example, I'm sure that an Angler is tied to a Tip, but is a Tip tied to 1 Angler or can 2 or more Anglers share the revenue from selling one Tip? I also noticed that Honeyhole is off on its own, not connected to anything else in the system, so it is most likely an attribute of a Tip and not an object. I also think, "What is the difference between a Tip and a Post?" They seem difficult to differentiate, which is a sign that it will probably be difficult for users as well. Doing this in advance uncovers questions to discuss as a team.

System Model / Relationship Map

Next, I created an Object Glossary that defines each object at a high level. It's also a place to write down examples and other potential names or labels. For example, while I was writing the definition of an Angler, I noticed that the terms Anglers and Fishermen are both used, so it will be good to clarify which term we will use. In addition, I wondered how we would differentiate the two types of Anglers in the system - Buyers and Sellers. Also, are objects such as Advertisers and Ratings necessary for Phase 1? I keep updating this document throughout the process as new info emerges.

Object Glossary


There was a good bit of documentation for this project, so everything up to this point was preparation for workshops with the client. I led the workshops and a fellow UX'er and a Product Manager were part of most sessions.

Gathering Context

At the first workshop, I probed to understand clients' motivation for building the app, what the need is in the real world, how the product will make money, and for this app, how people currently get fishing tips. During this time, so much great information emerged that was super important, as we couldn't do research for this project.

  • 🐠 What is the need? Fishing is incredibly nuanced. There are so many details to think through (I had no idea), and it's not easy to learn. Hence, the reason anglers ask the experts. Anglers with insight need a way to monetize their knowledge.
  • 💸 How will the app make money? Initially, a brokerage fee will be charged during checkout and a listing fee charged after the seller posts a tip. Eventually, advertising and affiliate links will be incorporated. 
  • 🎣 How do fishermen find tips in the real world? First, anglers think about the location/body of water, then the fish species, and then think through more nuanced techniques. Modeling this in the app will be key.

Exploring the Objects

Next, we discussed each object at a high level. Right at the start, we quickly got into this great conversation around the difference between a Tip and a Post by simply trying to define them. A Tip would be purchased, and a Post would be something that an Angler could share to build their reputation. We discussed how people might have difficulty differentiating them and how Posts could bring unnecessary complexity for Phase 1. Is it necessary for a proof-of-concept? 

We also discussed how Instagram and FishBrains, an app for fishermen to brag about their hard-earned catches, already do Posts very well. They wouldn't be able to compete. So, they decided to focus on Tips, and Instagram and FishBrains can be used to drive people to the app. As we wrapped up, the client said, "Wow, this just saved us $50,000 and a headache." Ah, the beauty of a discovery and taking a bit of time upfront. 💗


Exploring the Relationships

Venturing onward, we explored the relationships between the objects, which always brings about great discussions and discoveries. It's a structured way to bring clients into the complexity. A few things emerged: 

  • An Outfit needs to be added to the system. An Outfit employs guides who then take customers out on fishing trips. Our app would need to model this, as this is what happens in the real world. Outfits will get a percentage of the revenue in the system when Anglers who work with them are out on trips and post tips. An Outfit would also need to be another role in the system.
  • We had a lot of discussion around Reviews and Ratings. So much complexity was discussed, and in the end, we arrived at a very simple solution to reduce the complexity for Phase 1.
  • New objects emerged, such as Recommendations and Messages.
Relationship Map

We also started to clarify what should be included in Phase 1, which is everything underlined in pink in the image above. After the workshop, I transferred all of this information to a Relationship Matrix in Google Sheets, which ensures that every relationship is explored and defined.

Relationship Matrix

What are the attributes of a Tip?

The juiciest object in the system is a Tip, and we had a lot of discussion around its attributes. It was important to model how Anglers think about Tips in the real world.

"Anglers think about the location/body of water, then the species of fish, and then think through more nuanced techniques."

The primary metadata is the body of water, then species, and finally techniques/methods, which then breaks down into smaller categories.

Object Map

Discussing the attributes brought about a discussion surrounding what information you can purchase on a Tip and the cost of each. A few concepts emerged, again thinking about what fishers need in the real world:

  • $ Techniques (lure, bait)
  • $$ Waypoints (specific location of fish)
  • $$$ Talk to the Angler (hop on a phone call to get all the details)

At first, we thought these would all be able to be purchased separately. For example, if you're on a Tip, you could just buy the Technique and not the Waypoint. However, after discussing this for some time, we decided that if you purchase a Tip - you purchase everything. It would bring too much complexity for the sellers when creating tips and buyers when purchasing if they are separated.

Understanding the Actions

We explored each role's actions (buyers, sellers, and admin) and what they can do to each object. For example, a Buyer needs the ability to follow an Angler, and a Sellers needs to be able to add a Tip.

The two main actions affect both Buyers and Sellers - "Purchase Tip" and "Talk to Angler." At first, we explored putting both of these on the Tip page. After deliberating, we decided to separate them. "Purchase Tip" will be on the Tip page, and "Talk to Angler" will only be on the Angler page. The functionality of each CTA is different, and placing the "Talk to Angler" on a Tip could be confusing as they aren't trying to talk to a Tip, they are trying to talk to an Angler. Direct manipulation for the win.

CTA Matrix


During the workshops, we created flows in order to explore questions such as:

  • Can Buyers view the app without creating an account?
  • Can Buyers checkout as a guest? 
  • How is the flow of creating an account different for a Buyer vs a Seller? 
  • How will a Seller call a Buyer?
  • How will the admin role function? 

Working through the flows in the workshops ensured that we were all on the same page at a high level. This will also provide a birds-eye-view of the app for developers, stakeholders, PMs, and designers.

Illegible Flow for Buyers and Sellers ;)

Putting It All Together

Object-Oriented UX Deliverables

I transferred all of the information that was originally in Whimsical to a Google spreadsheet and Notion (for the Object Map). These documents are used to document the system and can be used to guide the design and development phase.

For example, as I design, I can use the Relationship Matrix to know that I will need to include Anglers on the Tip, as they have a relationship. The Relationship Matrix can also be used by engineers developing the back-end. When designing, the Object Map helps me understand which attributes go on which cards and detail pages and how filtering will work.

OOUX Deliverables


I'm currently working on the wireframes - once complete, I'll add them and some details below. Here is the current state of affairs.

Current wireframes

Product Requirements Document

I'm also creating a high-level product requirements document that will be used to guide the process moving forward.

Next Steps

Most of what is covered above is only the first round of OOUX. At the start of a design phase, I would do a second round, gathering more detailed requirements. Then, I would start designing screens while developers start on the back-end. The Phase 1 product would be built, and when the app goes live, it's a wild success. 🎉 😉

What I Learned

Exploring user flows with clients 🌊

In the past, user flows were created after the workshops were complete. I saw how beneficial it was to explore these topics with stakeholders as it ensures we are all on the same page at a high level. If time and budget permit, this is a must-have.

More listening than talking 🙉

I've been looking to take my listening skills to the next level. These workshops were a great time to practice. Really dropping the ego and being open to different perspectives can be challenging, and I used to this time to keep practicing. I more clearly saw where stakeholders were coming from, used the time to think critically and generate thoughtful questions, and paid attention to if we were getting stuck in complexity loops.

Going with the flow vs staying on task ⚖️

Going with the flow while staying on task (and moving things forward) is a tough balance to strike. I start each workshop with a plan, but if a different topic arises that we need to cover or explore, I noticed the benefits of going with the flow - and then knowing when to change directions if necessary.