Jonathan Snook's Blog, page 21

Cleaning the Cruft

Cap Watkins had a good blog post about The Dark Corners of Your UI. In it, he talks about how there are parts of a product that can easily become neglected.

At Shopify, we often have the same. We’ve recently assigned a designer to review a number of these dark corners and shine some light on them.

Cap is right in that many product teams won’t give these areas much priority. As a product manager, I usually tried to tie these efforts into larger endeavours instead of trying to knock them off one by one.

As a front-end developer, however, these corners often result in stale code and interfaces that are outdated and don’t match the rest of the product.

One of the things I did was to do an audit of every single page, including blank slates, onboarding, and external pages.

Each page is colour coded to indicate whether it uses a different layout and CSS file than the rest.

As we continue to revamp and refactor code across the entire application, we have something to reference to ensure that areas don’t get missed.

We’ve also created a Design Systems team that is responsible for establishing patterns across the entire product and this site map provides an inventory of all the pages where those patterns are used.

In doing this, we hope to keep the spotlight on quality and avoiding any build up of cruft.

Unmanaged

I've been a product manager for a year and a half. That came to an end this week and I'll be returning to a life of front-end development.

Product management at Shopify has been in a bit of limbo for a few months while the CEO considered a possible restructuring. That restructuring happened. But what problem needed to be solved, organizationally?

Shopify continues to grow, with many new teams splitting off to specialize in various parts of the Shopify ecosystem. This has been sorely needed. But each new team didn't necessarily require a dedicated product manager. Often, a person within the team—a dev or designer—can act as that product captain. We had naturally seen that occur on a few teams already.

With all of these teams, though, I felt we were missing someone overseeing some of this work, leading to inconsistencies within the product. I wasn't the only one who felt this way. As a result, product directors were put in place to manage the handful of product concerns within Shopify and a mix of product managers and product captains report to the product directors.

The short-term impact of this on the practice of product management within Shopify has been a shrinking of the product team. The long-term impact remains to be seen but there's hope that more people from beyond the product team will feel empowered to push the product in exciting ways. (At least, that's my hope from these changes.)

While I wanted to be a product director and pushed hard to get the role, it didn't happen. Instead, I'll be moving back into front-end development, to push the speed at which we develop products from a different angle—one that I'm quite familiar with.

Alas, this is the end of this short-lived adventure in product management. At least, for now. Thanks for following along.

Consistency

I originally wrote this post about a month ago and never sent it. Things have since changed at Shopify. As a result, I have one more post to follow to wrap things up.

I saw this tweet that asked, "When you group PMs, developers and designers by project, how do you maintain a consistent user experience and design?"

I've read and heard about how Spotify (ahem, not Shopify, where I work) does it via a presentation on scaling agile. Namely, chapters or guilds where those of a similar discipline get together to share.

However, I don't think even the Spotify model necessarily addresses the question from the tweet. Does having all your designers getting together help maintain a consistent UX and design?

While conversations within a guild are good, I think it's still necessary to have someone in place to direct the product and establish that consistency across the board, especially at a design level. I believe that someone needs to be the decision maker. The Product Owner. For some companies, that's the CEO. The product just isn't big enough to need more than that. For larger companies, I think it makes sense to have people responsible for that consistency within a "tribe" (borrowing from the Spotify model).

At Yahoo!, for example, the design team I worked on was responsible for a suite of products. UX and design were made consistent across the suite.

Shopify, to date, has tried to solve this problem using Product Groups. Product Groups are like a chapter but grouped around related products. In one case, that would be store management. There's no leader of the group; it is driven by consensus.

However, this has only officially been done at the product manager level. At the engineering level, we've seen this happen unofficially and with good benefit as patterns are codified and distributed to other teams, resulting in a better and more consistent product overall.

At the design level and UX level, we haven't had this and it's something that I've been encouraging to happen. Sections get designed or redesigned but done differently—sometimes dramatically so—by each designer. I think it's important to have someone to ensure consistency in design, experience, and features across the entire product line. Someone who can see how all the pieces intersect and knows the product intimately.

Rethinking the Grid

At Shopify, we’re rebuilding much of our front-end code for Shopify Admin. This is giving us the opportunity to re-evaluate why and how we build things.

One of the first components that we decided to work on was the grid.

24 Column Grid

Shopify has, for at least the last two and a half years that I’ve worked there, a 24 column, percentage-based grid. This type of grid is quite common in the industry and one that many designers like.

As we talked about what our new grid system should be, some designers on our team pushed to keep the 24 column grid that we already had. Predictable, flexible, and familiar.

Code Audits

I did an audit of how many of those twenty-four span classes were being used and perhaps unsurprisingly, a fourth of them were unused.

Another fourth of the classes were used only a handful of times.

These types of code audits are very useful because they help reveal opportunities for optimization.

I’m not a fan of creating code on the off-chance that it might be used someday. The code audit revealed that we could lighten our load.

Making it easier for everybody

One of the goals was to have a system that was easy for designers and developers alike. If a new cell is added in a row, the design shouldn’t just fall apart.

Looking at the design, we noticed that most of the time, we just needed cells of equal width.

With Shopify Admin, our browser support is kept to modern browsers and with that came quick consensus among the team: “let’s try flexbox!”

We let flex-grow do its magic. Cells become equal width and new cells can be added without breaking the design.

.grid { display: flex; }
.grid__cell { flex: 1; }

Not every row is going to have equal width cells, though, and this is where we ran into some contention on the team.

My original proposal was to use flex-grow to achieve cells of different weights. flex-grow: 2 in a row of 3 cells would produce one cell at 50% width and the others at 25%.

This had a couple limitations, though:

It didn’t allow a lone cell in a row to be less than 100%, andpadding throws off cell calculations for which box-sizing doesn’t help. (`flex-basis` solves the padding issue.)

We decided to augment our system with a few percentage-based classes: .grid__cell--half, --third, --quarter, and --fifth. This solved the two limitations we had with the previous approach and works well with the default .grid__cell.

.grid__cell--half { flex: 0 0 50%; }
.grid__cell--third { flex: 0 0 33.333%; }
.grid__cell--quarter { flex: 0 0 25%; }
.grid__cell--fifth { flex: 0 0 20%; }

What’s next

We’ve created the grid but have yet to roll it out across the site—and deal with any of the unforeseen issues that may come out of this approach.

Right now, it looks like flexbox will give us a flexible (pun unintended) system with less code. That’s a win-win.

Book review: Making it Right

A new book on product management just came out, published by Smashing Magazine, called Making it Right: Product Management for a Startup World.

I lucked out and noticed that it was available for $1. Yay me! The book is still a reasonably priced $9, though and TL;DR: it's worth the $9. At 170 kindle pages, the book makes for a quick read and has plenty of linked up resources to get you on your way.

Making it Right seems aimed at those just getting into product management or introducing product management into an organization. Having seen this process occur at Shopify, which went relatively well, I think the advice provided is good.

The book starts off with an explanation of what product management is and how to introduce it to your organization. From there, it dives into the planning and execution stages of product development. Some of the process stuff felt a little too specific and detailed. I've seen tool after spreadsheet after document languish due to its inability to really be of much use for the duration of a project. The book is also highly targeted to those doing web product development.

My biggest complaint with the book was that it felt more like a series of blog posts. The structure—linking off to numerous resources—works well for the web but is awkward and distracting when trying to stay focused with the book at hand. I read the book using the Kindle app on my iPhone, which means that I get some colour and resulted in distracting red (for callouts) or blue text (links) throughout.

All in all, Making it Right is a good overview of what product management can be. It'd be worthwhile for any person in an organization to read this to get a better sense of what's involved in being a PM.

PM Learnings: What is a Product Manager?

I've been a product manager for over a year now. I'd like to think I've learned a lot along the way. I want to document that journey to date and into the future.

Issue 3

So, what is a product manager? matbalez wrote a good piece on that very subject. I especially liked this one quote:

"You live and you die based on your ability to convince other people to
do what you need them to do for the good of the product."

I have a team and am expected to lead the team but have no direct reports. Nobody answers to me. I'm the one building the battle plan and explaining why this is the war we should be waging but someone else is executing the plan. (Not that building a product is a battle. I find it quite enjoyable but I needed an analogy so go with it.) 

One of the first articles I read on being a product manager was Good Product Manager, Bad Product Manager (PDF). It's interesting to go back to reading it now after a year. "Good product managers err on the side of clarity". I thought that my team knew what our priorities were. To make sure, I decided to ask in a meeting, "How do you decide what to work on?" I was surprised that nobody knew what our priorities were. What seems clear to you might not seem clear to anybody else. You can't just tell. You have to ask, too. Likewise, you can't just point people to some internal tool and say that the roadmap is clear. 

For a team to stay focused, they need clarity on priorities. At Shopify, I manage a central part of the product and have people from every part of the company and outside the company looking for their problems to be solved. We (and I) need to be incredibly diligent in maintaining our priorities. It has been surprisingly easy to see that derailed by the next person who walks into the office with a question. 

To be sure, I don't have it all figured out. I'm still learning how to solve these problems.

If you'd like to follow along more closely to this journey, subscribe to the newsletter.

PM Learnings: So here we are

I've been a product manager for over a year now. I'd like to think I've learned a lot along the way. I want to document that journey to date and into the future.

Issue 2

So, here we are...

I started at Shopify in a design role. We didn't have a product team. No product managers to speak of. As the company grew, the need for a product team also grew. When the role was described to me — someone who takes in research and helps prioritize and design product features — it sounded like a great extension of what I was already doing as a designer. Turns out, I had a lot to learn.

A Product Manager's Job is one summary of what it's like to be a product manager. I've taken the first point very much to heart and I've shifted the way I operate. Before, I was more of a "to-do maker" and a "decision maker". Problem was that the moment I wasn't around, I felt like progress would easily get derailed.

Now, I try to help my team prioritize work and provide them with anything they need to get their job done. Specifications, reviews, coordination, notes and whatever else helps them accomplish the objective. 

Kenton Kivetsu covers the 3 skillsets for PM success. The first of which is getting stuff done, which includes prioritization. Coming up with priorities seems easy enough. The hard part has been having to say no to other people who want to throw things onto the top of the deck. Communicating why things are prioritized the way they are becomes a very important skill.

Deciding on what will have the biggest impact can be difficult. I mentioned The Innovator's Solution and The Discipline of Market Leaders in the last issue. I left off Red Thread Thinking. It's, admittedly, probably my least favourite of the three. Some interesting stories but very little seemed to really create a compelling strategy that I could apply to my work. 

If you'd like to follow along more closely to this journey, subscribe to the newsletter.

Product Management Learnings

I've been a product manager for over a year now. I'd like to think I've learned a lot along the way. I want to document that journey to date and into the future.

It's the inaugural issue of the newsletter. I'm kicking this one off with a bunch of books that I've read plus a couple articles to boot. Expect more of the same in future newsletters. If you have any article suggestions, feel free to ping me on Twitter at @snookca or via email at jonathan@snook.ca. Thanks for following along!

The Innovator's Solution: Creating and Sustaining Successful Growth eBook

The Innovator's Solution is much more technical than I expected and does a great job of breaking down what's needed to avoid "the innovator's dilemma".

The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market eBook: Michael Treacy, Fred Wiersema: Kindle Store

This book is a great companion piece to The Innovator's Solution. This book is older, having been written near the end of the 1990s. It's also not as technical of a book as The Innovator's Solution. However, there's plenty of good useful bits to frame where where I work now (Shopify) to the concepts outlined in the book.

Book: Lean Analytics

Part of the Lean series, Lean Analytics teaches you to "Use Data to Build a Better Startup Faster". Useful for determining what metrics to track and determining your KPI.

Top Hacks from a PM Behind Two of Tech's Hottest Products

"I don't see the PM's job as having all the product ideas. I see it as keeping the engineering and design teams firing on all cylinders." There's so many useful bits in this lengthy article that speak to the heart of product management.

But what IS the Minimum Lovable Product?

Despite the title, the article mostly focuses on how to rapidly prioritize stories and using that to figure out what the minimum "lovable" product is.

If you'd like to follow along more closely to this journey, subscribe to the newsletter.

More Simple jQuery Slideshows

Over 4 years ago, I wrote a really simple slideshow script using jQuery. It just took a bunch of images of the same dimensions and cycled through them. The code is only a few lines long (jQuery notwithstanding).

Since that time, however, people have often asked for variations. I've updated the demo page with most requested variations.

Linking the Slides

Sure the images rotated but you know what's even better? Being able to link the images to specific pages! This was by far the most popular request. The original code was very specific to images. With a few minor tweaks, the script could be made to cycle through all child elements, whether they're images, divs, or links.

$('.fadelinks > :gt(0)').hide();
setInterval(function(){
$('.fadelinks > :first-child').fadeOut()
.next().fadeIn().end()
.appendTo('.fadelinks');
}, 3000);
});

References to img elements begone! The CSS also needs a minor tweak to target the child elements. I used this child selector, which means that if you have to support IE6, you'll need to make some more CSS adjustments to make it work.

.fadelinks { position:relative; height:332px; width:500px; }
.fadelinks > * { position:absolute; left:0; top:0; display:block; }

Random Images

Having the images go 1-2-3 is a little too predictable for some. Wouldn't it be nice if it could be randomized? This required a bit more work but barely. Imagine the images are like a deck of cards. I take the top card and put it on the bottom of the deck. Then I pick a random card and move it to the top of the deck. Repeat.

$('.faderandom > :gt(0)').hide();
setInterval(function(){
var rand = Math.floor(Math.random() * ($('.faderandom').children().length-1));
$('.faderandom > :first-child').appendTo('.faderandom').fadeOut();
$('.faderandom > *').eq(rand).prependTo('.faderandom').fadeIn();
}, 3000);

First, I need to get a random number. I use this with jQuery's eq() method to pick a card from the deck and move it to the front of the deck with prependTo(). This is still a tiny amount of jQuery to pull this off.

Multiple Slideshow

My original script was very simple and only worked if there was only one slideshow on the page. You had to copy/paste the script multiple times changing just the class name to point to the new slideshow. That's not very DRY.

Now I started writing more code than I really felt comfortable with. There's probably a more elegant way to do this but I put this together really quickly. And, well, it still works. This time, I loop through each slideshow and store the currently selected slideshow in a closure for use within the setInterval call.

$('.multipleslides').each(function(){
// scope everything for each slideshow
var $this = this;
$('> :gt(0)', $this).hide();
setInterval(function(){
$('> :first-child',$this).fadeOut()
.next().fadeIn().end()
.appendTo($this);
}, 3000);
})

And that's it! More simple slideshows.

Floated Label Pattern with CSS Only

I came across Brad Frost's post about the Floated Label Pattern and instantly thought, "I think you can do this in CSS" and set out to prove it.

It turned out to be a little trickier than expected but I created a quick proof of concept:

The Example



First Name

Last Name


How it works

I use the :valid pseudo class along with the pattern attribute on the input to style the associated label accordingly.

.field { position:relative; font-family: Arial; text-transform:uppercase; font-weight:bold; display:inline-block; }
label { position:absolute; left:0; top:0; transition: all .2s linear; color:#999; font-size:10px; }
input { margin-top:15px; border:1px solid #999; padding:3px 2px; }
input:invalid + label { top:3px; opacity:0; }
input:valid + label { opacity:1; top:0; }
input:focus { outline:none; }
input:focus + label { color:#33A; }
Problems with this

The label has to appear after the input. I'm using CSS trickery to get it into place. I'd love to be able to put the label first in the content but there's no way to style an element based on the content that comes after it.
It relies on the pattern attribute and the :valid pseudo class, which means that they can't be used for other things like validating email addresses. It'd be nice if there were a different pseudo class that I could use that detected presence of content.


.field { position:relative; font-family: Arial; text-transform:uppercase; font-weight:bold; display:inline-block; }
.field > label { position:absolute; left:0; top:0; transition: all .2s linear; color:#999; font-size:10px; }
.field > input { margin-top:15px; border:1px solid #999; padding:3px 2px; }
.field > input:invalid + label { top:3px; opacity:0; }
.field > input:valid + label { opacity:1; top:0; }
.field > input:focus { outline:none; }
.field > input:focus + label { color:#33A; }