Once I’ve determined what problems to tackle in the near term, I find it useful to create a “one-pager” to synthesize my thoughts around a problem/project. This is after the point where discovery research has been done, and I’ve talked with the team (including tech leads, designers, and another product manager) about the idea. 

I’ve listed the sections I found most useful to include, both for myself to confirm it’s a project worth tackling, as well as for the designer to read before they start designing. (Keep in mind, I’m only a few months into being a product manager! But this is what I’ve done so far)

For me, these are to help guide the team as they begin thinking through details; it’s not meant as a functional requirements document, nor should it be overly prescriptive. 

Several resources are included at the end of this article; I highly encourage you to check out John Cutler’s article and/or video for some great insights and frameworks around this idea.

I’m in the process of moving from being a UX Director to being a Product Manager.

Along the way, I found it quite interesting just how similar the two roles often are, at least based on the job description. Others considering switching between the two roles might find this useful – in fact, as soon as I posted that I was making that move, someone messaged me to ask about the difference!

I may write more about the overlap once I actually start as a product manager, but for now, here’s a quick look at some of the similarities and differences in job descriptions between the two, taken from a few different job postings (listed at the end).

Note: both roles are defined fairly differently from company to company, so always read descriptions carefully. And take this with a grain of salt, as these are based on just a handful of examples.

This post is about four (almost) tool-agnostic best practices to follow when you do any kind of formal design deliverable.

I recommend these best practices for two reasons:

1. Easier handoffs – improve your ability to share your file across team members / with clients. This is especially important these days, when you’re not sitting next to someone who is using your files
2. Reduced maintenance – make it easier to maintain files over time, so small updates don’t require lots of rework

Aligning on these ‘rules’ as a team will help improve efficiencies.

My four ‘best practices’ are:

1. Set up your grid/layout
2. Use symbols/components/masters
3. Use styles (text/layer/effects, etc.)
4. Organize your file, including naming things as needed, changing the order of layers, etc.

Continue reading →

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