Whether you call it discovery, strategy, requirements, research, or inception, the first 20% of a design project can make or break it.

Get it right, and the team works in concert, toward well-understood goals and following clear principles.

Get it wrong, and your project collapses into a disorganised mess. In this workshop, we'll look at what makes for great discovery. Discovery is not just about conducting research and holding a kick-off meeting.

Discovery is establishing the design problem and setting a direction for the solution. It’s about collaborating with the team to build a shared understanding of the constraints and context. It’s creating a foundation from which you can confidently make decisions throughout the design process. It’s agreeing on a plan for detailing and implementing the product design.

We will talk about essential tools and techniques for discovery. We'll look at how research fits in, how to write great design principles, and how to incorporate discovery into any project situation.

You’ll get:

• The essential ingredients for any discovery phase
• The range of discovery activities and how to choreograph them
• What deliverables come out of the discovery phase
• How to incorporate discovery into new projects and projects in-flight

You’ll try:

• Crafting your own problem statement
• Mapping out a discovery phase
• Planning a design workshop
• Outlining a discovery deliverable

You are:

• A designer of any level who need a better handle on doing discovery
• A product manager who wants to understand how to integrate discovery into your team’s work

It’s been 20+ years since the advent of IA, isn’t it about time we had more tools for our work? Enter IA Lenses, a new tool to help IAs evaluate and interrogate their concepts by looking at them from unique perspectives.

Information architecture remains the hardest part of the design process because it deals with abstractions. Even if you’re designing a navigation system, that part of the UI reveals only a small part of the underlying structure. Since design thrives on critique, and it’s difficult to critique something that’s abstract, designers need better tools for making decisions about a product’s information architecture.

After designing navigation websites and frameworks for digital products for 20 years, I realized that on every project I asked myself the same set of questions about the underlying structural decisions. These questions are the very critique that helps me move the design process forward.

Each question is a lens, through which I examine the structure. I choose a label for a category and ask myself, “What’s missing from the implied contents of this label?” I nest one category in another and I ask myself, “Even though this belongs here, does it bury an important concept?” I develop a set of top-level categories and ask myself, “What story does this tell about the organization?” The purpose of these lenses isn’t so much to determine correctness, but more to look at my decision from all angles. They let me dig deeper into my decisions to make sure my thought process is robust.

In this session, I’ll share some of the lenses, how they’re used, and how you might apply them to different IA challenges. As a consequence of articulating these lenses, I’ve also come to some realizations about the practice of information architecture itself.