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.
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.
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.
