Jon Plummer

You’d be forgiven for thinking my employer doesn’t have a blog. It (and the website it’s a part of) haven’t been updated in a while, and while the content is interesting, it’s a little wooden and sparsely published, to the tune of an article or two per year in past years, and none this year.

“Thought leadership” is a line item on every director’s or VP’s job description, and we’re told it is important. The suggested ways to demonstrate thought leadership are by the blog, giving conference talks, and by participating in standards committees (useful for our edtech products and clientele). A very few people are in position to participate in the standards committees, and the rest of us are not holding up our end.

You’ll probably see why, looking at our posts. Their length and production value is fairly high, with illustrations and pull quotes and tight editing to reflect the company voice and tone. They fit into a fairly narrow band of design and development process and technique, with some loftier edtech concepts and product announcements rounding out the list. And I’m told they take weeks to produce and go through a fairly strict approvals process.

At some point soon I’ll be on the hook for a revised “thought leadership strategy,” an assignment I made up and gave myself because I don’t find this situation satisfying, and because I think that our ethos of continuous improvement leads us to experiment with techniques, tools, and process all the time so we are always learning. And we’re not just learning about edtech standards or design and development technique; we’re operating on team processes, people management, equity and inclusion, social responsibility, accessibility and usability, research and discovery, client management, pattern-oriented design, staff development. We are chewing on every part of the business we are in. So chances are we have lots to say. And we’d like to put not just a human face, but real human faces on our work and the portrayal of our company.

The past manner of producing blog posts looks to me like a series of expensive hurdles between a person who is eager to share something they’ve learned or realized or succeeded at and a far-off blog post that’s going to be enough work to squelch the impulse. But perhaps we can overturn these hurdles. Maybe we can “what if” them away.

What would it be like if we didn’t have an extensive approvals process? What if instead we had guidelines, and helped people to comply with them when they were not? That would probably be easier for everyone, and we could update the guidelines as we learned from the process.

What would it be like if, instead of tightly editing each post to fit into the company voice and tone, we let the voice of the author shine through? We could edit for clarity and basic grammar and be done with it. The voice would be the person’s, the tone would be appropriate to the material (and we may have some weighty topics to discuss; no need to force everything to be technical or lighthearted), and the people will see their own expression, personality, and esteem in the posts they produce.

What would it be like if, instead of having to present news (we launched!) or a fully-fledged method or conclusion, we were to talk about things we were trying to do, or learning about, or experimenting with? We might not feel so called to present a federal case about a technique we had chosen and then feel stuck with it.

What would it be like if we opened up the allowable topics to cover essentially anything we were learning or experimenting with at work? Folks on my team are wresting with including a blind person into the design process, bringing content-first techniques to data-driven tools, packaging research as a product, bringing clients to rapid usability testing in the midst of short sprints, development of junior staff, and many more interesting topics. We may not always have something completely new to say about these things, but we can talk about what we are trying and, later, what happened and what we’ll try next.

What would it be like if, instead of insisting that posts be weighty, we were to allow short ones? A paragraph or two about things learned when discussing a meaty topic might be just as valuable as, and a ton easier to bang out than, a lengthier, lighthearted post about a nice result we have produced for a client.

Imagine a company where essentially any employee, not just a few in the management class, has the ability to post, and knows how to make a good post. We might have a process by which a person, inspired by a meeting or with a fresh thought about an experiment we should do, could bang out a quick post before the rush fades, and we can make up for a few high-production-value posts with a flood of smart thoughts from real people, trying hard every day, if we manage to release each of these brakes.

Mr. Bias wanted folks to look over his new portfolio, and I was happy to help. He’s a new UX/UI Designer and what little appears on his site is promising. Here’s what I had to say:

Hey there.

I like a lot of what you have here, and you were smart to grab your own domain name. I’m sure it’ll look more impressive once you have a couple more projects on there.

As a hiring manager (who is, alas, not hiring at the moment) I’m interested in

• seeing what your contribution to the project was (especially your THINKING contribution to the project)
• seeing how decisions were made and what you learned along the way
• seeing those insights made visible in the mockups or prototypes

I even have a rubber stamp that I use on resumes to see what characteristics or capabilities I can find clues about in a person’s materials:

• Research (user research and secondary research)
• Prototyping (self-explanatory)
• Testing (user testing!)
• Graphics (not a strict requirement for a UX role, but often helpful)
• Delivery (quality of deliverables – are they organized, explanatory, easy to follow)
• Communication (is organized thinking made obvious in speech and writing)
• and bonus skills (is there anything else this person can do that might be useful or reflects intellectual curiosity)

So I’m watching for signs of people being interested in these topics, doing them, and hopefully doing them well or progressively better. Happily all of these things are expressible or at least hintable in an online portfolio such as yours.

Your writeup for Pay the Poet is straightforward and sensible, but it leaves me wanting a little bit more re the above items, especially what you (or the team) learned. I think this is mainly because you have some fairly uninformative statements in there such as “Poets love the Instagram UI.” This is a bit of a “so what”—what do they love about the UI? Emotionally, functionally, etc.? You do mention that they are used to Insta’s upload interface, which is specific. Specificity, plainly spoken, is your friend here.

Another, “PayPal is a popular and secure method of payment that users trust” hints that there’s more there, but you don’t go further. What other payment vehicles did you ask about? Is anything important beyond trust?

These things seem to me pretty easy to fix, but will require some introspection.

On the other hand, there’s a whole line of inquiry that could be useful to discuss coming off of “Poets want exposure and a means to build a following.” This is the sort of meaty starting point for an interesting app + service. Right after that you say “Poets want to be able to connect with fans and those who seek to book them.” I like this one too. I wonder if you have more to say about these.

Take care with statements like “after our first stand-up, we decided to create a screener survey which informed us what type of digital product to create”—a survey never tells you want to do, but that’s what you are saying here. My guess is that your interpretation of the survey results gave you clues about the way forward that you then needed to explore, yes? Probably not answers per se.

I like the “How Might We”s and wonder what more you might say about them that’s specific.

I like that you called out your specific contributions later on in the write-up. I’m hopeful that your other writeups will show off other capabilities. Early in a UX career there’s not much room for specialization.

It would be nice to know what unique or interesting interactions you were attempting to express in your wireframes. Wires on their own are rarely sufficient to explain to a developer what you are trying to make, and I’m watching for clues that you can relate the concepts you’ve put there in words as well as pictures.

I like that you express some insights from user testing. This is evidence of learning, an important signal for folks beginning their careers.

Did you or the team think of potential future work for this product? Features that aren’t core now but might be useful later? This isn’t required, but it’s a clue that you are thinking about the user’s needs and the product outside of the immediate context.

I hope this helps. Please feel free to ask me questions if you like.

Also, I dig your About page. There’s a kernel in there that might be useful in discussions with hiring managers, or could even get more play elsewhere on your site. Poor UX in software, hardware, services, or what’s often called CX (customer experience across channels) leads directly to customer pain and support calls, making products and services less profitable. At Belkin this was a real issue – if we made a design or technical mistake in the setup of a product, each individual call would suck up all of the profit for the device the user had purchased. So there was a lot of pressure to learn about the problems users were bringing to customer service to try to keep costs down through design and development – through improving quality. You are uniquely positioned to make good use of what your brethren in customer service are learning every day from customers.

Later in the discussion I finally made the point that I seem to have to make with every new designer:

I can guess that you did a lot of the right activities and learned some stuff when you speak in generalities, but learning and good thinking is made obvious when you speak in specifics. There’s something a little bit “college essay” about generalities, and business demands specifics. So if there’s something interesting or surprising you learned that mattered to the project, telling me specifically about that, in plain language, is more powerful.

M.C.Seigler has a somewhat inspirational take on the Salesforce acquisition of Slack, namely that

I believe that much like with Apple 20-some years ago, the timing will be right for the experience of using something to matter to the point where it changes the equation not just of a market, but of the entire world.

And that

 I believe such a change will happen in the enterprise as well.

He points out that this will likely be a slow process. And it will; it _has_ been a slow process for decades already. The fact that enterprise _buyers_ are often not adept, day-to-day enterprise _users_ has kept focus squarely on development cost at the expense of quality, ease, (ironically) cost of support, and a thousand tiny daily charges against goodwill as people wrestle with awkward enterprise software.

But the shift from in-house enterprise IT to SaaS and managed services has set the table for competition on experience and lower cost of support. SaaS teams with enough _focus_ can compete on experience quality at whatever scale if they remember to continuously reconnect with their users.

Dear by Humankind folks:

I love what you are doing and have progressively bought more by Humankind products over time (and tried to turn friends on to them). It’s inspired me to find ways to reduce plastic and packaging elsewhere in my life. And it’s also inspired me to consider how things might be redesigned to reduce their throwaway parts. So, if you’re willing, I have some ideas about your deodorant refills and dispenser.

Near as I can tell there are three “throwaway” plastic parts in a deo refill: the carrier, the screw, and the cap.

First up is the cap – it gives the deodorant its nice domed shape, but since you have it mated with a cardboard tube it doesn’t really do that job all that well; there’s always quite a bit of flash around the top of the deodorant, and the cap is sometimes hard to remove (I’m on my third refill, and two of them have took some tugging). So that injection-molded plastic cap could probably be replaced by a cheaper and lighter plastic film or possibly even paper. That would also allow you to get a little more deo material in the refill. The domed shape comes soon enough through use. This change would probably not disrupt any part of the customer experience and certainly wouldn’t demand more from users – in fact, it may be easier for them to use.

Next up is the carrier, which pushes the deodorant up when the screw is turned. This probably can’t be done away with, alas.

Finally, the screw. It’s kind of a big injection-molded part, and cast into the deo material, which makes it easy for users to manage. But depending on the level of work you are willing to ask of your customers, it could be a non-replaced part of the dispenser rather than a replaced and discarded part of the refill. This would require the user to screw the refill onto the knob and screw, then insert that assembly into the sleeve, which is a different and more difficult process. But it would knock off one screw per refill, or about two-fifths of the total plastic per refill. This would be a disruptive change also because you’d have to change dispensers, and thus obsolete and replace a set of existing dispensers. But it might fulfill part of your mission better, if done early enough.

A less-disruptive form of this would be to stop shipping screws in each refill and just have people keep a screw from a previous recent refill – they could screw the screw into a screwless refill, then install it the usual way, and you could ship screws to folks who need them or who buy new dispensers.

An alternative would be to collect all three of these parts, but that would lead to more shipping and you’d have to clean and inspect them before reintroducing them to manufacturing. Better to reduce than reuse.

Anyhow, food for thought. I certainly don’t expect or demand you make any of these changes, but figured you might find these thoughts interesting.

At work we are soon to reconsider how we do annual reviews. But we lack a shared sense of why we do them, and they are performed with different levels of seriousness in different parts of this small company.

Unfortunately, signals from leadership are (likely inadvertently) mixed: reviews are important, feedback and development are important, but with raises “sort of on hold” due to the pandemic, reviews are as well. Reviews aren’t all about money, but they are suddenly seemingly unimportant and all about money since the money is at issue.

I don’t say this to be critical of our leadership; the situation has been come by honestly over a long history. But it’s confusing to folks who have not grown up in this particular work culture. This is one of those all-too-frequent situations where a little more professionalism goes a long way.

In the meantime, I have people on my team who want to have their reviews, and I want to give them. And I just had my one-year anniversary, and want to have my own review. So we’re going to do them unofficially, with the slightly reluctant blessing of the leadership team, separate entirely from thoughts of compensation.

There are nice parts of these reviews: they involve an extensive self-appraisal, they involve peer feedback, they aren’t forced into a ranking or a five-point scale. But there are troubles as well. There’s little guidance to managers regarding performing these reviews. There’s scant relationship between the reviews and the mission or values of the company. And the reviews all end with an overview and compensation discussion with the very busy company president. So the connection between feedback and compensation is starkly underscored.

I’d much rather reviews be separate from compensation, since de-fanging them in this way allows them to lean more fully toward constructive feedback and the future rather than proving that past behavior was worthy of money. And now I have the chance to tilt the few reviews I’ll be a part of in this more helpful direction.

The peer feedback is also solicited in a vague way, with essentially two questions: do you have constructive feedback for the reviewee, and do you have any other feedback for the reviewee? I suspect these are not specific enough for any but the most committed peers to do a good job of addressing.

If I recall correctly, IDEO likes to evaluate their employees along four dimensions

• Content – what is the quality of a person’s delivery
• Commerce – what is their contribution to the success of their clients and the firm
• Collaboration – what is their manner for working with the teams they are on
• Culture – what is their contribution to the culture of IDEO

I think we can adapt this notion – the commerce piece in particular is a little more distant for many of our people. But we could bend it a bit toward

• Quality – HMT (how might they) contribute to better results for the users of the product/project
• Content – HMT improve the delivery of their own work
• Collaboration – HMT foster greater collaboration among the team
• Client – HMT better serve the needs of the client
• Improvement – where have we noticed improvement in the review period

I plan to try this on by doing my two coming reviews with these dimensions explicitly in mind, and using these to solicit peer feedback. I’ll let you know how it goes.

Gentle people,

It’s a moment of uncertainty and anxiety (election), piled atop a lengthy period of uncertainty and anxiety (pandemic, police killings, climate change, fires, etc.) with no real end in sight. I get it if you’re distracted. It’s fine—expected, even.

Be kind to yourself. And if you like, let me be kind to you, too. Let me know if you need help. Need to clear the decks? I can help. Need things to do to be distracted? I can help. Need to get something off your chest? I can help.

Don’t want to talk about it? Fine. Want to talk about it? Fine. I’m here for that, either way.

We will gratefully greet the sun in the morning.

I have near two year experience doing oversea marketing from a leading international NAS company called Synology. My role was devising marketing strategy and implementing it in our New Zealand and Australia market. (These two markets earn Synology over 1 billion revenue annually) I was the only marketing person who looks after these two area, so I have to run user/market research, devise product and content strategies, build campaign website with development, hold offline trade shows, perform copywriting, release product PR/ writeups and strategically distribute all the marketing materials to various channel outlets (including enterprise and consumer channels).

I came across UX in a marketing campaign where I design the website from scratch and attracted millions of impressions within two months. I realized that I’m interested in how experience shapes user behaviors, as well how they make decisions. By looking into users in both qualitative and quantitative lens, I hope I can play a more product-oriented role in a firm. That’s why I decided to pivot my career.

Thanks for reading these long paragraph and would love to hear any suggestions from you!

Hello, Daphne, Sorry about the delay. I read your note with interest; since you have some experience in product marketing you might be more ready than your peers to engage design goals at a higher level.

Design goals are the marriage of user goals and business goals. The ideal product, design, or business intervention brings success to the person being served and the business doing the serving.

In my early days at a past employer some product management leaders arrived from Procter & Gamble. They brought a method of product definition that changed the way I look at design. To hear them tell it, a solid product concept depends on some insight about a customer, some insight about the competition, and a way of delivering a benefit to that customer in a way that is informed by these insights and thus distinct from your competitors. It may not have a direct competitor at all, if your insights are insightful enough.

An insight is a statement of fact about a situation or behavior that is obvious in retrospect, but hidden or overlooked to most observers. An example: if you ask married men in the US why they shave their faces, they may say something about their spouses liking them to have a smooth face. But if you examine common shaving behaviors you’d see these same men shaving on weekday mornings before work, and letting their stubble grow on the weekend, just when they’d be spending the most time with their spouse. Clearly their motivation is elsewhere; it turns out that their behavior demonstrates that they shave to demonstrate a professional appearance at work.

A benefit is the result of having or using your product, expressed in general terms. It’s especially important that the benefit be a result, rather than a product itself. It’s also important that the benefit be expressed in general terms; the benefit could perhaps be delivered by means other than your product. In the shaving example, the benefit of a comfortable, smooth shave every morning could be delivered via a razor, or a shaving powder, or perhaps carefully-targeted lasers. The method is important, but the benefit does not state it.

I mention these product marketing concepts, benefits and insights, because interrogating them can usefully inform the work of product design and help others on the team, such as engineers and QA people, understand the intent behind the product being developed.

Asking about benefits and insights can also help you detect where research may be needed to strengthen the case for a product, to improve the benefit, determine how to demonstrate the benefit, or even where the product management is lacking. It’s common for newer product managers to rush headlong into assignments where they are asked to deliver a feature without really delving into the benefit that feature is meant to deliver. During design and development the forces of budget, timeframe, and technology can distort a poorly-understood benefit and put the design and development effort at significant risk. Attention the the benefit, why the benefit is relevant, and the various means available to you of delivering the benefit, can help you craft an intervention that is at the right scale for the business and really meets a customer need.

There’s one more product marketing concept that is important here: reasons to believe. A reason to believe is a fact about the product that helps the consumer understand that the product really will deliver the benefit it promises. RtBs come in many forms, such as endorsement (Kobe wears these shoes, the American Dental association recommends this toothpaste), explanation (a diagram of the product in use, a video), demonstration (see my white teeth), comparison (this router is 15% faster than the leading brand), proof (clinically proven to reduce cavities), a visible feature, a named feature, reassurance (money-back guarantee), or a testimonial (Joe here really enjoys his stump jumper).

If you are working on a feature for a product, and you understand the benefit, you can more easily give your user the scent of that benefit early in the interaction and demonstrate that you have delivered the benefit later in the interaction. This is just good design practice, but by asking the right questions you can get to a potentially successful design faster.

At one point the Linksys app, meant to offer people setup, control, and monitoring of their Linksys networks at home, was rated below three stars on the iTunes Store and had a lifetime rating of 3.3 on the Google Play Store. A new information architecture, a fresh coat of paint, and many performance and interactivity improvements brought it to 4.5 stars on iTunes and a 4.1 lifetime on Google, helped by a judicious amount of review solicitation.

My role: Product owner, leader of the design team and cajoler of the software and firmware engineering teams. Substitute product manager for a somewhat neglected area. Part-time scrum master for design and blended design/development teams.

Lessons learned: The performance characteristics of the framework you choose to develop with need to align closely with the performance needs of your product. The framework is meant to make life easier for developers but needs to do so in a way that explicitly conveniences users. Said another way, the negative performance characteristics of the framework you choose better not matter to your users or you’ve magnified pain of development rather than reduced it. Asking otherwise happy people to review your app, infrequently, increases the recommendability of your product. A fresh coat of paint is not enough, but failing to give a fresh coat of paint once in a while enhances feelings of neglect, deserved or not.