TUG helps organizations get better alignment on the vision of the software they want to create. In the built world, this is achieved through PLANNING that produces MODELS - representations of a place that can be used to scope out the engineering and crafting tasks needed to create the thing the design describes. The Understanding Group relies on models to get broad clarity as well, although in the case of software, it’s not a single model or specification, but multiple models.

All software development operates from some initial vision that is expressed through varying kinds of specifications. Whether these are traditional waterfall requirements, user stories in a backlog, or a checklist, they all represent an attempt of human minds to express to builders a need. And most of them, in one way or another, largely fail to do so.

TUG argues that the failure to produce novel products that match an initial vision is caused by a disconnect between the intent of the organization and the development teams trying to realize it.

New problems in business — especially in internet-heavy contexts, where the concepts involved are changing at massive speeds — are the kinds of problem sets that demand rigor. Rigor is a way to validate, verify, and align understanding of complex concepts. Only after the "what" is developed and the "how" begins to come up during design and creation should formal models get in the driver's seat.

Web technology is increasingly modular and flexible. So what remains is developing a language for design and architecture that best supports that flexibility. One starting point for this language is to see sites like many architects see buildings: as layered structures with different degrees of stability.

The most difficult part of technology isn’t keeping up with what’s new. It’s being thoughtful about how technology is going to change the structure of what we can do to serve humans in digital places.

Software developers often raise common objections about Information Architecture—but they aren't really problems at all. They say things such as: “This is just a waterfall process”, “You can’t understand anything until you try to build it”, “We’re just going to have to start requirements over again”, and “We already have an architect.” These objections speak to the primary tension in software development with projects: Making is not the same as understanding.

When you build websites, are you letting technology drive your decisions? Or are you considering the purpose and language of your site BEFORE you start to code? Language is tricky. People use the same word to mean different things, and different words to mean the same thing. When we talk to people in real life, we use the context of the discussion to understand what is meant. On a website, that’s harder. The information architect’s job is to build that sensible, coherent system of language to help your visitors get oriented.