I'm not a fan of LessWrong – while I like the idea of being more rational, and strive to acknowledge and feel my emotions but not let them impede my thinking needlessly, there's a strong whiff of holier-than-thou coming off of many in the rationalist community, including the otherwise very interesting Scott Alexander, whose writings on mental health care I admire. A little humility goes a long way but it is sometimes in short supply.

Nonetheless I was happy to read Anna Salamon’s article Humans are not automatically strategic. Though the article makes heavy use of the trope of calling the less-rational populace "humans," as if rationalists are somehow better than mere humans, the core of the piece lays out an eight step process to develop and pursue goals that is very much like the method I came to the hard way over many years, and try to coach the people I support into using.

(a) Ask ourselves what we’re trying to achieve; (b) Ask ourselves how we could tell if we achieved it (“what does it look like to be a good comedian?”) and how we can track progress; (c) Find ourselves strongly, intrinsically curious about information that would help us achieve our goal; (d) Gather that information (e.g., by asking as how folks commonly achieve our goal, or similar goals, or by tallying which strategies have and haven’t worked for us in the past); (e) Systematically test many different conjectures for how to achieve the goals, including methods that aren’t habitual for us, while tracking which ones do and don’t work; (f) Focus most of the energy that *isn’t* going into systematic exploration, on the methods that work best; (g) Make sure that our "goal" is really our goal, that we coherently want it and are not constrained by fears or by uncertainty as to whether it is worth the effort, and that we have thought through any questions and decisions in advance so they won't continually sap our energies; (h) Use environmental cues and social contexts to bolster our motivation, so we can keep working effectively in the face of intermittent frustrations, or temptations based in hyperbolic discounting

Point (a) seems to be where so many people fail. What is it that you want? What should happen? If it were magic, where would we be already? Some of this is using question (b) to back into (a), which can be easier, sometimes. But (b) is really about measurement—making your goal operational.

(C) and (d) are research. People often forget to do this, or find it unexciting. That could be a clue that you're not as interested in your goal as you thought (see point (g)), but in these times many find our intellectual persistence has been weakened by the many available distractions of social media, especially the FOMO that comes with that. It's all to easy to envy or look down on anyone you come across on Twitter, Instagram, etc. and it doesn't help you be you if you are buys inspecting others.

(E), systematically test many different conjectures, is an advanced form of what I wish people. would do, which is just try something and see how it goes. That makes a lightweight form of (f) possible—see if what you are trying is working, and make a change if not, based on (b). (H) is similarly advanced. A lighter form of this, more than adequate to start, is to take notes on your plan and results so you can refer to them later, and do so.

Any creative professional (and I use the term broadly) eventually needs to create a system for themselves (or adopt and then adapt one) to organize their thoughts and plans. One's head is the least reliable storage. Doing so can help make being strategic possible.

To me, someone who didn't go to business school, the all-too-common admonition to “make the business case" for something was often a showstopper. What is a business case, what does it include, how do I make one, and what hard questions need be answered when making it? I had no idea where to start. And even my best bosses were no real help, handwaving vaguely about time and costs and benefits and whatnot.

It turns out that, aside from some large businesses that have a very specific format for an internal proposal, they were handwaving vaguely because they didn't have anything more specific to say, and because some of their words carried meaning that wasn't obvious.

It took me a long time to figure this out. I finally pinned someone down while I was early at Belkin and fairly interrogated them about the "business case" that seemed so daunting throughout my career, and learned that there's not really much to it. You could bash together a business case for whatever without too much trouble, I bet.

Sure, there's the matter of benefit—that's a bit of business jargon that refers to the desirable result of doing a thing, said in a way that doesn't depend on how it is achieved. For example, we would like to have a more inclusive workplace. There are lots of things we could do to get there. Improving the inclusion of underrepresented groups in our hiring pipeline is one tactic we might use to help achieve that benefit.

So this business about benefit, time, cost, etc. is correct, and really about expressing a problem, a benefit to counter the problem, and then offering possible methods and their costs that will help achieve the benefit.

I wrote a little memory jogger to help build these. It's not much to look at; I'll bet you can fill it out pretty easily as you think about a problem you are trying to solve. A simple proposal, not too expensive or time consuming, can be just this in an email. A fancy proposal will need more flesh, but the anatomy is the same:

We have (problem) It costs us this (in treasure, pain, missed opportunities)

A way forward is (solution) It will cost us (how much) to get started (in treasure, people, space, equipment, etc.) In the first (timeframe) it will yield (result), based on (the similar experience of others) Ideal for us is if it ramps to producing (result) Other opportunities it might create include (stretch)

There’s also (alternative solution) It’s better than the other (because) It’s worse than the other (because) It will cost us (how much) to get started (in treasure, people, space, equipment, etc.) In the first (timeframe) it will yield (result), based on (the similar experience of others) Ideal for us is if it ramps to producing (result) Other opportunities it might create include (stretch) Etc.

Any part of this you can’t answer can be answered with the help of folks in your organization, folks you know or learn about via working the network, or can be left asked but unanswered. You'll need to talk to these people anyhow to gather support for your proposal, so you might as well include them early—involving people in creating the future that they will be part of is really the only good way to create buy-in.

Recently I've started to knock this sort of thing together into a little proposal format. It doesn't match the above exactly, but you'll recognize the themes.

A specific and action-oriented name for the initiative

Background

Explain the situation that gives rise to the problem and any useful facts about the situation that will be good to know as people read through the proposal.

Problem

Express the specific problem you’d like to go after, more plainly and directly than suggested in Background.

Our Aim

State the desired benefit. For example, Elevate the average employee’s awareness of inclusive work culture and behavior, and equip them to participate in small local interventions when necessary.

Proposed Intervention

Explain the concrete steps you plan to take to achieve the benefit.

Cost and timeframe

Talk about what it would cost, and how long it would take, to do those steps. Consider initial costs, recurring costs, whether we're "done” at some point. Bonus points if the costs and time line up exactly with the activities in the proposed intervention.

That should be enough to get most ideas out of your head and into active discussion in your company, club, homeowners association, etc.

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.