Recognizing Constraints An Article by Jeremy Wagner css-tricks.com Super Nintendo games were the flavor of the decade when I was younger, and there’s no better example of building incredible things within comparably meager constraints. Developers on SNES titles were limited to, among other things: 16-bit color. 8 channel stereo output. Cartridges with storage capacities measured in megabits, not megabytes. Limited 3D rendering capabilities on select titles which embedded a special chip in the cartridge. Despite these constraints, game developers cranked out incredible and memorable titles that will endure beyond our lifetimes. Yet, the constraints SNES developers faced were static. You had a single platform with a single set of capabilities. If you could stay within those capabilities and maximize their potential, your game could be played—and adored—by anyone with an SNES console. PC games, on the other hand, had to be developed within a more flexible set of constraints. I remember one of my first PC games had its range of system requirements displayed on the side of the box: Have at least a 386 processor—but Pentium is preferred. Ad Lib or PC speaker supported—but Sound Blaster is best. Show up to the party with at least 4 megabytes of RAM—but more is better. constraints
Collaborative Information Architecture at Scale An Article by Brandon Dorn www.viget.com Here I describe an approach for defining new information architectures for large organizational websites managed by many stakeholder groups. Broadly speaking, there are four general phases to the approach: Auditing. Begin by immersing yourself in existing content and encourage stakeholders to adopt a critical, audience-minded perspective of their content. Diagramming. Work with stakeholders to develop new conceptual categories that better serve audiences and organizational direction. Elaborating. Think through content in detail and test new categories against specific instances and edge cases. Producing. Prepare content teams for production using a shared database of new sitemap pages and editorial considerations that you’ve developed incrementally. Half of design is facilitation The Ladder of AbstractionA Pattern Language decisionsorganizationpatternsanalytics
Half of design is facilitation At least half of the work of design is not design, because design isn’t just "making things"—it’s making things with other people, many of whom usually aren’t designers. This is true any time you’re working with others from a domain outside of your own. Communicating ideas, marshaling stakeholder consensus, soliciting and incorporating feedback, and redefining problems that weren’t fully known at the start are all the non-design work of design, what we might generally call "facilitation." designcommunication