Batman: Arkham City (Tutorials, Structures, Scaffolding)

Call of Duty: Modern Warfare 3 (Rhetoric, Composition, Pedagogy)

LA Noire (Enthymeme, Paradigm, Multiliteracy)

Reposting with audio commentary!

Magic the Gathering: Building a Deck and Usability Testing

Usability testing is a process often associated with web design and provides interested parties with information about how audiences understand, interact, and use a specific product or "text". Most companies and parties seeking information from a usability test often seek out testing toward the completion of a project, as Steve Krug explains in Don't Make Me Think: A Common Sense Approach to Web Usability, but Krug encourages testing earlier and testing more frequently (142). However, a product or "text" must be created before any testing occurs, much like how CCGs like Magic: The Gathering cannot be played without a deck and both concepts begin with a hypothesis.

For example, web designers hypothesize about an overall design scheme for a web page or website and then hypothesize about specific design elements they may or may not include, which often involves researching different possibilities before making deliberate decisions about what to include. Similarly, Magic players hypothesize an overall deck concept and then research potential cards using resources like their collection, Gatherer, or Card Kingdom, until cards are finalized and a rough draft of the deck is built. For example, here is a draft of a Black / Blue deck I recently completed:

Main Deck (60 Cards)
12 Island	2 Hedron Crab	2 Jace Beleren
12 Swamp	2 Liliana's Specter	2 Liliana Vess
	2 Abyssal Specter	2 Tome Scour
	2 Hypnotic Specter	2 Archive Trap
	2 Shimian Specter	2 Traumatize
	2 Gravedigger	2 Twincast
		2 Liliana's Caress
		2 Megrim
		2 Elixir of Immortality
		2 Dark Ritual
		2 Jace's Erasure
		2 Jace's Ingenuity

The deck hypothesis I imagined when I constructed this deck is using Blue in order to "mill" an opponent's deck (winning may result from opponents not being able to draw cards from their library) rapidly. Black's role in my initial hypothesis is assisting with targeting my opponent's hand through dealing creature damage from specters and forcing them to discard.

As a result of usability testing (playing a draft of the deck) and collaborating with my colleague, friend, and superior Magic player Mike Salitrynski, I realized that my deck's hypothesis is sound but things go wrong in execution. The revisions made test my hypothesis further, but result in a stronger overall product, which is an important goal usability testing makes possible.

Here is a final draft of the same Black / Blue deck after two days of playing at least three games with it:

Main Deck (60 Cards)
8 Island	4 Hedron Crab	4 Hymn to Tourach
8 Swamp		4 Doom Blade
4 Jwar Isle Refuge		4 Twincast
4 Salt Marsh		4 Vision Charm
		2 Ostracize
		2 Liliana Vess
		2 Blackmail
		2 Despise
		2 Monomania
		2 Traumatize
		2 Jace, Memory Adept
		2 Jace's Erasure

For instance, one major revision resulting from usability testing is rebuilding my mana base, which now consists of half basic lands (Island / Swamp) and half dual-lands (black or blue mana producers). The mana change allows more flexibility per turn since my hand often consisted of black and blue cards, but I did not always have the right mana to play anything. Another significant change is relying on Black spells targeting an opponent's hand and forcing discards at a much faster rate using less mana per turn.

Overall, technical communication is about fast and clear communication, which often involves managing resources and understanding how to achieve results as simply as possible. The process associated with building a deck in card games like Magic demonstrate key principles related with usability testing, but also with understanding writing as a recursive process regardless of genre.

Final Fantasy XIII-2 (Menus, Submenus, Terministic Screens)

Mega Man 9 (Time on Task)

Castlevania: Harmony of Despair (Remediation)