I got laid off today. That's not a win, surely. But it set off a few:

• The moment I announced I am #openToWork on LinkedIn there was an inrush of good wishes and referrals and recommendations.
• The surviving and departing members of my team spontaneously gathered to provide mutual support. Their comments to each other and to me are really heartening.
• I remembered to create an alumni Slack, and some people who left prior to this layoff are showing up. As with the flameout of my previous company, there are good people who formed good relationships and are happy to band together.

And, to be honest, it's a bit of a relief.

Two basic activities

There are two basic activities in UX.

• Learn
• Make

You might call these "understand" and "design," or "investigate" and "generate," or whatever. It's the same. There's nothing fancy or proprietary about any of this. But you have to do both. If you learn and don't make you are more knowledgeable but don't have a solution to the problem. If you make and don't learn you have a thing, but an indefensible one, with no way of knowing if it is any good.

You might learn to make making easier, or you might have to make some things in order to facilitate learning. You might alternate between learning and making. You might learn, make, make, learn, make, etc. But you'll do both. Sometimes making just captures what you've learned in a form you can use later.

Yeah, this is basic stuff. Baby steps. Even so, some teams fail at this level.

Three "horizons"

I like to think of product delivery, and thus the work of research and design, in three segments or horizons.

Horizon one is the horizon closest to whatever we are hoping to ship soon. I call this the "detail" horizon. It involves creating workflows, selecting and laying out controls, defining behavior, formative usability testing, implementation support, and instrumentation. Most teams seem to do most of their work in horizon one. That's an anti-pattern; without adequate attention to the other horizons, work in horizon one is poorly-supported, organizations aren't learning, the designs are accidentally good at best and indefensible at worst. Horizon three is the farthest out. In the third horizon we're looking for problems we might solve for our existing or prospective customers, and proposing benefits that will address those problems. Call it the "benefit" horizon. Most teams leave this horizon to product managers and executives, though they shouldn't. Executives especially can fall into the trap of leaping from horizon three to horizon one, or even shortchanging horizon three in an effort to get to horizon one quickly. Horizon three is learn-heavy, but there's making in proposing benefits that the team may choose to deliver.

Between horizons one and three is horizon two. This is where we bridge the gap between a benefit and a specific design. I call this the "concept" horizon because there are many ways to deliver a given benefit, and we need to figure out some concepts and choose among them before getting into the details. I've witnessed very few teams that explicitly work in this horizon, and the quality of their delivery suffers.

I'm still chewing on this

One quibble I have with this "horizons" idea is that they aren't numbered sequentially; for a given product you work in horizon three, then horizon two, then horizon one. But naming them works and provides a handy mnemonic for the overall workflow: "benefit, concept, detail." That might be more powerful than speaking in horizons.

Surely there's more

Yep. These are just the bones. Flesh yet to be written about:

• Specific learn and make activities in horizons one, two, and three
• How product, UX, and engineering should interact in each horizon
• Double diamond, single diamond, how many diamonds and how large
• Scaling the process up or down to be responsible the task at hand
• Other philosophical points important to this process

• I'm using a process initiative at work to demonstrate to the company, especially to folks not on the product team, a basic UX research and design process. The main idea is to short-circuit the all-too-common impulse to leap from an identified problem or need to one seemingly obvious solution. Executives are famous for this, but it's common in other parts of the company as well. Executives are also famous for mixing generation and evaluation, which should be held apart for a while.
• Going hard at the gym has started (at long last) to result in less or even no knee pain at night, leading to better sleep. Hallelujah.
• I'm getting closer to a unified field theory of UX research and design. Watch this space for stabs at explaining parts of it at various levels. The first bullet above holds one fragment.

• My two conference talks went fine. It's not easy to gauge audience response when using some of these online conference platforms, so I'll reserve further judgement until the survey results come in.
• One of my online participatory design exercises went fine (the other was marred by low participation). These are hard to do online, but better than nothing, and we learned some things even so.
• I tried doing a pull-up on a pair of cannonball grips, and surprised myself by succeeding without much trouble. I haven't trained pull-ups for years. Maybe I should. (Word is you should "Spock" your grip on these, with two fingers on either side of the bracket at the top.)

There has been a lot of scuttlebutt about people secretly holding two jobs of late. This is partially due to a labor market that remains tight, especially in tech, publicity around fraudulent interviewees, and employees having more control over their time in remote and hybrid work environments, among other concerns. This has led to some needlessly inflated rhetoric and managers comparing notes about how to detect people who are working more than one job.

I'm not that worried about it. The number of jobs an employee has is not my concern.

• If the person is getting their work done and meeting my performance/communication/availability standards, I don't have a problem.
• If they are not getting their work done and/or not meeting my performance/communication/availability standards, I do have a problem.

In neither case do I need to cast about for proof that the person is working another job or two, or distracted by caring for an elder parent, or going through a messy breakup, or what have you. I gain nothing by investigating each employee to see if they might be working another job. If I determine that there's a performance problem, I need to talk to the employee and manage the issue.

No one seems to care if an employee in the C-suite serves on multiple boards (unless they are competitors) or advises multiple startups (unless they are competitors). No one seems to care if an employee also plays in a band. No one seems to care if a person sells their ceramics or tunes pianos or works on software projects on the side for free; perhaps it's conflict of interest we're worried about?

If there's no performance problem and no conflict of interest, is there a problem?