Product Management One-Pagers

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.

Continue reading
Screenshot of the landing page of People & AI Guidebook from Google

AI resources (for non-developers)

I was lucky enough to start my job as a product manager just as a machine learning project was underway! I was able to jump on board and get involved.

I’m glad I have built up a basic knowledge of machine learning over the past few years, as it was very helpful in being able to ask the right questions and have quality conversations with the lead developer.

I want to share some machine learning (ML) and artificial intelligence (AI) resources for non-developers interested in learning more.

Continue reading

Product Manager roles vs. UX Director roles

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.

Continue reading

Design document best practices for easier handoffs and reduced maintenance

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

UX Portfolios & Resumes: Curated Link Recs

I recently offered to review resumes or portfolios for up-and-coming UX grads, or those impacted by COVID (offer’s still open!). 

Rather than explain my rationale for a recommendation in detail, I often include a link to an in-depth article – and I’ve found myself going back to the same ones over and over.

This is my curated list of relevant best practice articles, as well as how-to’s and examples.

Continue reading

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.”

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