Communicating information architecture

Jackie talking and walking with a microphone, with a slide behind her that indicates do's and don't's for presenting information architecture

On Saturday, February 22, during the World IA day event at Kent state, I presented on “Communicating IA: Making the Intangible more Understandable.”

Just having great IA isn’t enough – you need to make sure everyone is aligned around your IA so you don’t run into problems down the line (“why are we writing content for that? I didn’t say we should have that on our site!”).

In the deliverable meeting where you’re presenting your IA deliverable, here’s a rough framework to consider:

  • Establish a purpose for the meeting
  • Set the context
  • Introduce the deliverable
  • Present the deliverable
  • (post meeting) Share the deliverable
Continue reading

Design team career guide sources

One of the challenges that I undertook in 2019 was to come up with a more detailed career guide for our team.
While I did a lot of work on this, it was iterating on what I had with the rest of the experience leadership team that truly brought the work to a level where it could be shared. 

We just shared it with the team, so no feedback on it yet, but I’m hopeful that the team will find it useful.

The biggest thing I learned – don’t start from scratch! There’s a lot out there that’s worth leveraging.

Continue reading

Diving into deliverable details

Before creating a deliverable, pause and think about two key things:

  1. Who’s the intended audience?
  2. What will they be doing with this deliverable?

You may have multiple audiences, and this is an exercise worth going through for each of them.
Your audience might include developers, designers, business stakeholders, project managers, account executives, etc. What they each want to do with your deliverable may be different.

Some examples:

  • Developers may want to use it to build something, or estimate a level of effort
  • Designers may want to use it for a source of inspiration or as input into design decisions
  • Business stakeholders may want to confirm the project will meet their business needs, or use your work to prove to someone else that a project needs funding

“Instead of always creating the exact same deliverables or whatever’s easiest – photos of whiteboards, powerpoint decks, Photoshop mockups – think about the audience for the deliverable and what you’re trying to communicate.” 

https://qwww.usersknow.com/blog/2016/7/28/the-right-deliverables

Once you’ve written down your primary and secondary audiences, and determined their goals, it’s time to work on the details of the deliverable itself. 

The following is an example of a useful framework for thinking about your deliverables. Taking a step back and thinking, “is this the right place on the [whatever] scale given my audience and their need?” can help you be more thoughtful about producing the right deliverable.

Continue reading

3 models of design orgs

Pic of the cover of 'Org Design for Design Orgs'
Info in post is based on chapter 4

This post is based on chapter 4 of the book “Org Design for Design Orgs: Building and Managing In-House Teams,” by Peter Merholz and Kristin Skinner. Overall, that book is one I’d highly recommend to anyone who leads design, or anyone looking to be a design lead. This is just my interpretation of a small piece of it. 

The book covers everything from design organization best practices, to team roles, to recruiting, to professional growth, and more.

Where should design go?

As companies come to understand the value of design, more are adding and growing their in-house design teams. However, companies are not always clear on how to gain the most value from these design teams. Where should these teams sit in comparison to the rest of the company? How should they be organized?

Merholz and Skinner have explained two common models, and recommended a model that seems to combine the best of both worlds. 

Continue reading

Introduce your deliverable to start off right

During my recent presentation on “The Usability of Deliverables: Making Deliverables Easier to Present and Use,” I focused most of my time on the first section, “introducing the deliverable.”

This is a relatively easy thing to do that can help prevent a lot of confusion and misunderstandings. And it’s not UX-specific – anyone who presents anything can benefit from this. A developer came up after the presentation and told me how useful he’d found it.  

Continue reading