Confusing terms: globalization, internationalization, translation, and localization

At work there’s been a move afoot to tag items in our roadmapping tool as “globalization,” “internationalization,” “localization,” or “translation.”

The executive level thinking here is that we are not offering our products globally, and need to be. So what do you do about that? You globalize!

To my thinking, though, there are universal requirements, things that the underlying product should do everywhere, and requirements borne of local data formats, terms of art, regulatory environments, etc. Universal versus local. Then there’s the work of offering interfaces and commendation in a newly-supported language, and the things you must do technologically to make your application able to deliver these universal and local requirements and serve interfaces and documentation in the correct languages.

To my thinking, a universal requirement is just a requirement. The special ones, therefore interesting to tag, are

  • localization: things that need to be done differently due to a locale’s needs – preferred data formats, regulatory environment, terms of art, etc.
  • translation: the actual translation of interfaces and documentation into a newly-supported language or English variant
  • internationalization: things that must be done technologically to enable us to address either of the above

A tag that would be applied to all or almost all of the items seems like it might not be that useful. Globalization is the goal, not a specific type of work. It probably doesn’t make sense to separately call out universal requirements, as these should be numerous. Most work should be universal.

Meanwhile, globalization also includes marketing and sales and support and other things. Trying these terms on wrt marketing: we want to globalize our marketing, so we consider the universal messages we want prospective customers to understand (which should not be a special effort), then we look at how these might need to be localized (made locally specific/applicable) and translated (in the right language), and what processes we need to internationalize (tech/process/people to enable the above) to make conveying these messages possible.

I might be thinking about this wrongly, but this is my current understanding.

Who “owns” accessibility?

Heather asked me yesterday “who owns accessibility?” That’s a fun question. I replied:

Accessibility is not owned. Who owns quality? It’s a team responsibility. To the extent that accessibility compliance, or release date, or the P&L is a “feature” of a piece of software it is owned by the PM, but each function has its responsibilities in accomplishing accessibility. Making these responsibilities explicit is necessary.

The folks with responsibilities mainly include UX (designing for accessibility), FED (engineering for accessibility), QA (inspection), and PM/PO (prioritization). These aren’t collected in one person’s purview around here until the CEO, so that’s not the answer to your question.

If we are to be product-led and not sales-led, PM has to insist on it (and manage competing priorities), maybe that’s part of the answer.

The “ownership” urge seems to sometimes dilute or deprioritize the responsibilities of others, which is a shame because we must work in concert.

How to explain a new job on LinkedIn?

As of nine weeks ago I have a new job at Cayuse. But how do I explain my accomplishments on LinkedIn when I’m so new?

Maybe I don’t. What if I instead explain what I am there to do? What would that be like?

I am building a design and research team to support the collection of 25+ disparate built and acquired products into a single coherent suite. Since I’ve recently begun, here’s what I plan to accomplish:
• Develop UX and UI design capacity and capability
• Add and develop UX research capability
• Install formative usability testing during design to de-risk detailed design decisions
• Install user insights research, concept design and validation
• Stand up a team and processes to build and improve a design system in visuals and code, for the product suite
• Gather and improve product personas to be an informative smaller set of personas for the entire suite
• Begin instrumentation of new features, to measure outcomes, by determining desired outcomes at the epic level
• Help the product team take advantage of existing pre-customer and post-launch data, such as customer success contact data, support forum and knowledge base behavior, RFP mining, sales demo feedback, etc.

I suppose over time I could exchange some of these for my accomplishments and my new plan. I’ve not seen this anywhere else. Good idea? Bad idea?

Laura Cotterill asks about lack of teamwork

In her post on LinkedIn, Laura Cotterill (one of my new coworkers) refers to Eric Chan’s post about teamwork and wonders why such a seemingly obvious mode of work is out of reach so much of the time. To which I responded

My impression is:
1) When we pressure people to overproduce we encourage them to defend themselves in ways that seem locally sensible but turn out to be anti-collaborative.
2) Financial planning, especially when the business is not self-funded, tends to require a forecast; that forecast hangs from a roadmap, effort estimates, and sales targets.
3) When a business sees the sales team as its economic engine rather than the product itself (sales teams tend to be good at preserving this impression), opportunities detected by sales get pushed onto that roadmap with less discussion than necessary.

Of these I find the first the most pernicious.

Sara Bermúdez asked about important mindsets for the future of work

In the Design Thinking group on LinkedIn, Sara Bermúdez asked:

I would love to hear your opinions on which are the most important mindsets for the future of work.

Naturally, I had a take on this:

I find I often have to nudge people out of what I’ve come to call constraint-based thinking. Focusing on and reacting to the apparent constraints in a situation can lead to a poor solution and a feeling of being stuck with that poor solution, a double-whammy of negativity. “We couldn’t do X because of A, we couldn’t do Y because of B, so we’re stuck with Z, like it or not.” Chances are good that there’s a way to meet the goal that manages or makes irrelevant these constraints that you’ll be happier with than where you are seemingly stuck, but it requires exploring ways to meet the goal rather than rattling around in a box of obstacles.

Steven Forth responded:

Are there skills we can cultivate that helps us escape from the self-imposed constraints of constraint based thinking?

So I elaborated a bit:

Sure. Some are implied above.

1) Identify and articulate a goal as a benefit (where a benefit is the happy result NOT expressed in terms of exactly how it is delivered).

2) Consider a person’s needs and a business’s needs together rather than separately.

3) When confronted with a problem or pain point, learn about and offer possible benefits (some folks call them “gain points”) rather than solutions, at first. Later you can design or select a way to deliver that benefit.

4) Think in scenarios: who arrives in what situation, when and where, with which need or goal to address or accomplish, and what can the system (or organization, etc.) offer them?

Note that most of these thoughts require a positive wording of the situation or aim rather than a negative wording. This might be the key skill, broadly useful but not sufficient on its own. You’ll see this in health fields when practitioners take a wellness perspective—rather than cease some harmful behavior like smoking, they’ll talk about replacing the habits associated with smoking with healthier rituals, moving nicotine delivery to a less-harmful medium where it can be managed, etc.

There are many other good comments there.

A quick note to the design team about meeting invitations

Gentle people,
I recently complained to the directors and project managers about meeting invitations

  • without agendas, or
  • without a clear goal, or
  • without a sense of what a person might be expected to do in a meeting, or
  • without a sense of what person might need to do to prepare for a meeting.

It turns out that, generally, the project managers aren’t to blame here. The VPs and directors are to blame more than we should be, but especially the populace—most folks are not that great about helping the folks they invite to a meeting be ready for that meeting.

This is a thing that design folks can be especially good at. We’re accustomed to thinking about others and their needs. All we need to do is remember to think about these at the moment we are scheduling the meeting.

The people who are coming to your meeting need to know what the meeting is meant to accomplish and how they are going to be useful. Please tell them by including that information in the invitation.

If we get good at this, others will notice.

A lightweight, improvement-oriented roadmapping process

There are lots of great articles about developing a roadmap for a product or service. But sometimes these processes can seem too heavy, too slow, or too strategic (is there such a thing?) for the task at hand. A lightweight process, aimed at selecting and ordering improvements rather than expressing an ideal and working toward it, can work when certain conditions are met.


  1. The product (or process or service) exists already.
  2. Stakeholders are certain the product does essentially what it is supposed to do, but are dissatisfied by the results.
  3. There are too many potential problems and potential fixes to clean them all up in a single project, though this is desired, or
  4. the political situation is such among stakeholders that choosing a good place to start will be difficult (some may not want their area touched, others may want to go first, still others may not want to work.

These conditions assume that the strategy is good, and that the stakeholders’ attempts to fulfill that strategy are based on sound choices, but are perhaps not well-executed.


To successfully produce a roadmap and manage the political situation among the stakeholders we must accomplish a few things:

  1. Uncover and arrange opportunities for improving the product.
  2. Group and sequence the opportunities.
  3. Plan the work for the first step on the roadmap.

Along the way we must be careful to:

  • Make good use of any work the stakeholders have done to date.
  • Demonstrate to stakeholders that we understand the current situation.
  • involve the stakeholders in determining the value and feasibility of addressing each opportunity.
  • Involve the stakeholders in negotiating the roadmap and selecting the first step.

Stakeholders appear in each of the four points above. We must bring them though this process and ensure that they are heard, and are at times active participants, but we must not become wrapped up in their shenanigans. There are defined points in the process where we involve them.

The process

1. Investigation

The first few steps of the investigation phase will occur together, and as you learn more you may find yourself returning to stakeholders for clarification, more information, or scope adjustment. The investigation phase typically takes the longest of the three.

  1. Stakeholder research to establish goals and wishes, and collect their ideas.
  2. Primary user and stakeholder research to understand existing needs and processes and learn of opportunities
  3. Review secondary research (research done by others).
  4. Express any found problems/opportunities (often pain points) in terms of their benefits (“gain points”) and likely features.
  5. Arrange these opportunities by theme to see if and where problems are concentrated.

Step four is critical: you’ll have detected many problems and pain points, but need to express them first in terms of a benefit you’d like to deliver rather that just a feature. Remember that a benefit is the result of having a problem solved expressed without regard to the exact method of solving it. If you learn that students struggle to fill out a financial aid form on time, it would be tempting to offer an advisor to help them. That’s a feature, and it might not be the right one; the benefit may be that students have the information they need to fill out the form quickly and submit it easily. Go ahead and offer features, but only after identifying the benefits. The stakeholders will help us choose features once the benefits are clear.

We arrange opportunities by theme now to see if it tempts the stakeholders to narrow the scope of the project. You have to start somewhere, and the earlier we can reduce scope the higher the likelihood that the project will produce a useful first increment.

At this point you’ll have be ready to show the stakeholders your understanding of the current situation and the opportunities you’ve uncovered. This will fulfill both “make good use of any work the stakeholders have done to date” and “demonstrate to stakeholders that we understand the current situation” reminders above.

2. Synthesis

You’ve produced the raw material necessary for the stakeholders to help arrange opportunities into a rough sequence. Depending on scope the entire synthesis phase could be done in one workshop, or it might require two with some thinking and preparation in between.

  1. Have a workshop with stakeholders to score opportunities by value and feasibility.
  2. Examine the high-value, high-feasibility opportunities for common themes, then sequence all opportunities within these themes according to value and feasibility. More doable and higher-value items come first, and valuable low-feasibility items come last.
  3. Have a workshop with stakeholders to arrange these themes in sequence according to feasibility and value.

Scoring opportunities for value and feasibility is a simple matter of placing these on everyone’s favorite business diagram, the 2×2 matrix. Items in the high-value, high-feasibility quadrant are potential good places to start. You’ll want a small but politically-effective number of stakeholders in this meeting; too many and it will be hard for the group to make decisions. too few and they won’t be informed enough to make good decisions.

This process requires you and the stakeholders to discuss how each of the opportunities might be met; what improvement (feature or change) would deliver the desired benefit. So we are sneakily involving the knowledgeable stakeholders in choosing improvements to deliver the benefits. They will feel useful pressure to help come up with high-feasibility ways to address high-value items.

Some items will be high-feasibility but low-value. These are nice-to haves that probably should not appear in the ultimate roadmap. Put them in a parking lot so that no one need be sad about them being cut outright. Still others are both low-feasibility and low-value. The stakeholders might have pet items among these. They should also go to the parking lot unless great ideas come up about how to rethink them, their value and feasibility jumps as a result, and the prior research supports their inclusion.

The themes that emerge from looking at the high-value, high-feasibility items are more informative than the rough themes we offered in the investigation phase, and will govern the arrangement of opportunities in the roadmap. And when you look at them you will likely see that some of these themes contain more high scoring items than others.

Offer these themes and the improvements they contain to the stakeholders in a workshop, and ask them to put these themes in order. If we could work on just one theme, which theme would we choose? That one will be first. By the end of the workshop you’ll have themes in a rough sequence, and within these their opportunities in a rough sequence.

You could stop here, but it is likely that the stakeholders aren’t done yet.

3. Negotiation

Now that you have a sequence of themes, and within those a sequence of improvements, you have a roadmap. But it puts some lower-feasibility items ahead of others just because of the themes they appear in. It also may offer a sequence that is awkward to accomplish, or doesn’t begin addressing top organizational goals early enough. Time for negotiation.

  1. In a workshop with stakeholders, negotiate tradeoffs in improvement sequencing to better meet organizational goals.
  2. Once that negotiation is complete, in that same workshop select one or a few items earliest in the sequence to make up the initial project.
  3. Then go away and plan and estimate the cost in time and treasure to effect that project.

If you have the right small group of stakeholders, they’ll notice that they can rearrange some items to have the roadmap better address systems, efficiency, or political factors, start delivering against key goals sooner, or have certain improvements essentially make decisions early that will be helpful when tackling later improvements. Let them make these tradeoffs. The integrity of the themes is not important; we used the themes as a tool to make the rough sequence easier to accomplish.

After the tradeoffs are done, look to the items at the early end of the roadmap for the scope of the first project. It is tempting to bite off too much; everyone is excited about all the things you’re planning to do together. It’s best to keep the scope of the first increment small, achievable, not too expensive. Short projects with narrow scopes are more likely to succeed, after all.

Why not define an ideal?

You’ll note that this process does not define an ideal end state nor attempt to arrange a roadmap to produce that end state. End-state-based design is interesting (and there’s a very nice process called Ideality that depends on an understanding of the ideal), but I’ve elected not to make use of it here. There are several reasons for this.

  • Producing an expression of an ideal end state, when there are lots of potential improvements, is expensive.
  • The sequence of roadmap items aimed at an end state is likely to be different than a value- and feasibility-weighted roadmap which leads to high value improvements more quickly.
  • Understanding and acceptance of an ideal end state tends to decay rapidly as business conditions change and new information and technology becomes available.
  • Commitment to an end state reduces optionality, the ability of the organization to make new decisions about the future as needed.

Instead, this roadmapping process relies on the improvements themselves and especially benefits they are intended to deliver to take the place of an ideal end-state. These benefits express the desirable future in a diffuse, less-specific manner. Indeed, the later and less-feasible an item on the roadmap the less likely it is to be developed. this is true fo end-state-based roadmapping as well; the likelihood that the organization will pursue the entire roadmap diminishes over time. Why not embrace this constraint?

Revamping my design leadership portfolio: research results

I contacted seven recruiters I had recently communicated with by whatever means we had spoken before. Most of them wanted to take the discussion to phone or a video chat, but for scheduling reasons I had to steer the discussion to email. Two were confused, one didn’t respond, and four said things that were helpful.

Three types of recruiters

My respondents agreed on three types of recruiters and their differences:

  1. Contingency recruiter – this recruiter gets paid a percentage of the your first-year base salary upon hire. It’s a numbers game: most of the candidates they offer to companies don’t pan out, so they have to rapidly evaluate and offer a lot of companies a lot of candidates to make their time pay off. These recruiters have the least knowledge of the hiring company and the role, and may not even have a contractual relationship with the target company. They have little influence on the target company’s decision and do the lest legwork to make sure there’s a good fit. You can find a job with the help of a contingency recruiter, but they are helping the company only minimally and want to get you to an interview as fast as possible, not as well as possible. They specialize in individual contributor or low-level managerial roles, where the numbers of applications and opportunities are both high. Their tools are primarily keyword searches on large recruiting platforms such as LinkedIn, Indeed, Glassdoor, etc. This recruiter consumes job ads posted by companies and in-house recruiters. A solid LinkedIn profile that discusses the right keywords, and a resume that mirrors, it are keys to success with this group.
  2. In-house recruiter – this recruiter is paid a salary by the hiring company, or is a contractor for them, and works solely on that one company’s behalf. They typically know the hiring manager and have worked with the hiring manager to refine their own evaluation of candidates. They may look at portfolios if they feel comfortable, and will read more deeply into a candidates profile so that they can filter more carefully and reflect that they have done this work to the hiring manager. They exert a little more influence in the hiring process, and work on positions at any level up to and including middle management. This recruiter posts job ads, sometimes in specialized locations. They do keyword searches to sweep up a lot of profiles, then comb through these to create a smaller volume of potential fits for the role. A solid LinkedIn profile that discusses the right results, and a resume that mirrors it, plus some evidence of the same in a portfolio, are keys to success with this group.
  3. Retained search recruiter, sometimes known as “executive search” – this recruiter is paid up-front to fill an important position, and if they are doing their job well will have a relationship with the hiring manager, understand much more about the company and the position, and will be working from a “spec” that is much more detailed than a job description. The hiring company may have told them to favor candidates who have worked at similar companies, competitors, or places that are doing work that the company wants to do. They often understand team dynamics and the political situation at the company that the candidate would become part of. As a result they must do much more up-front assessment, understanding the profile and portfolio and doing much more in-depth screening interviews before offering a candidate to the hiring manager. They are a true gatekeeper in the process. This recruiter typically does not post job ads. The ability to do fine in a basic interview without warning, plus a resume and portfolio that display the necessary skills and acumen, are essential to success with this group.

You can tell what sort of recruiter you are dealing with in part by the level of information they provide and their ability to answer questions. If they can’t say much more than you can read from the job description, or deflect questions about the role with a “that’s a great question for the hiring manager,” you’re dealing with a contingency recruiter. It’s up to you to look at the company and decide if you’d like them to send your profile to the hiring manager. If you are approached by the recruiter they could be in-house or retained. If there’s no job ad and they interview you while telling you about the position, they are likely retained.

To be fair, all recruiters will try to qualify you, will try to make sure you are articulate and interested in the right things, are open to the salary and duties the company is offering, and are willing to take the next step in the process. But they will spend different amounts of time on that, and that time scales directly with how helpful they are to the hiring manager and to you.

My assumptions

My respondents also agreed with some of my assumptions:

  • I assumed that a hiring manager who is not a product person will be seeking to add or improve the design function in their organization by hiring a seasoned leader who can evaluate current staff and processes, develop staff, hire, improve processes, improve integration of the design function with the rest of the business, bring new capabilities to the design function, and deliver results in doing so that clearly further the aims of the business.

This was unanimously supported.

  • I assumed that a hiring manager who is a product person will have goals for the improvement of the design function, but will not be able to accomplish it on their own due to too many people and/or product lines to support, rapid growth, expertise or interest gaps, or other structural challenges. They may have a strong sense of the signals they are looking for, but regardless of that will be helped by clarity that I can tick all the boxes as a design leader.

This was unanimously supported.

My respondents were not in unanimous agreement about other assumptions:

  • I assumed that a recruiter is going to try to match my profile to the “spec” they are given, either a job description or something more specific about the signals the hiring manager is looking for. So a recruiter will be looking for these signals in my resume, and possibly in my portfolio. They are not likely to be expert in experience design, so the recruiter will be watching for general quality of portfolio items and that the right topics are mentioned or otherwise evident.

I learned that successful retained search recruiters will have more expertise in the role of the target, and some in-house recruiters, especially for large firms, also specialize. These people will evaluate portfolios with a critical eye and set aside candidates that don’t seem to have relevant experience, much as a hiring manager doing their own recruiting would. In addition, retained and in-house recruiters will also be looking for credibility in the treatment of topics such as design thinking, design systems, and process. Portfolios that demonstrate these are seen as more valuable even if the general quality of work is less-well understood by an individual recruiter.

  • I assumed that whether a recruiter is the first hurdle or not, the needs of the different types of hiring manager will be essentially the same.

In smaller organizations the hiring manager may do their own recruiting, and will have less patience to go through many profiles in depth. You’re likely to be quickly rejected if your fitness as a candidate isn’t immediately apparent. As the hiring manager rises in the ranks of a hiring company, the importance of each hire increases but their ability to spend a lot of time on recruiting falls, making it increasingly important that profiles advanced by the recruiter are high quality. So the interesting difference is less the hiring managers’ needs (all hiring managers need quality applicants) and more the level of assistance they are given (or can afford).

For me

I also asked these recruiters about my own profile. They found the following items important:

  • Experience with hardware and software
  • Experience managing cross-functional teams
  • Evidence of design thinking
  • Roadmap or other work to inform or assist product management
  • Evidence of process – this was fine but there could be more
  • Direct-to-consumer work – one recruiter felt this was lacking, which probably means I didn’t portray the audiences adequately
  • Evidence of design systems – this was lacking somewhat
  • Evidence of design workshops – this was lacking somewhat
  • Client-facing work – this was lacking

I note that none of the recruiters mentioned other joys of mine, such as developing design talent, integrating research into company decision-making, mentorship of designers and managers, or harnessing existing data sources to improve products. I could usefully make more of these points. I should not write a lot more in portfolio pieces or resume entries to try to fill in these gaps; every word should do hard work, especially in these settings. Too much prose won’t be read at all. So I’ll need to find other ways to accomplish this.

My expectations as a design leader and manager of people

Expectations of myself

  • Foster an ethos of continuous improvement
  • Repeatedly return to user needs and goals to create alignment
  • Frame design goals as the marriage of user goals and business wishes
  • Exhibit genuine care for each person I support
  • Use wisdom and humor when shaping behavior
  • Model desired behavior and attitudes for others
  • Address what’s needed wherever it appears

Expectations of designers

  • Scenario-based, goal-oriented
  • Use storyboards to start understanding a scenario
  • Freely move between storyboard, workflow, wires, prototype as needed to tackle problems
  • Make small prototypes to test and learn
  • The prioritization and arrangement of data directs user attention and action
  • Organize “done” work into bite-size chunks, set apart from exploratory work

Expectations of all workers

  • Work to make the job of the next person easier
  • Work in public, out in the open
  • Go and see
  • Be aware of and have your work informed by user goals and business needs together
  • Create possibilities cheaply, winnow according to goals, improve the best ones
  • Involve others in solving problems, chewing on possibilities
  • When presenting possibilities, arrive with your own evaluation of each one – pros and cons, fit to purpose, what you like and don’t like – and the sort of feedback you need
  • Scope is negotiated – watch for improvements AND for lighter interventions
  • Experiment with possible improvements to your own and collective work

Revamping my design leadership portfolio: setting up initial research with recruiters

Recruiters I’ve recently spoken to about passive opportunities (where the recruiter reached out to me before I was aware of the position) are more accessible to me than hiring managers, so my research will have to start there. In a previous article I said

The first step in capturing passive opportunities is clearly to get my profile in front of relevant recruiters. LinkedIn seems pretty good for this. While my LinkedIn profile is also not a subject of this research, I’m sure I’ll learn things relevant to it along the was as well.

The second is to get that recruiter to invite me to an interview so I can get them to pass me to the hiring manager if the position seems to be a fit. My impression is that my resume does an okay job here, and my portfolio could do better. I don’t know how many good opportunities have not com my way due to insufficiency of my portfolio, and I’m not sure I have a way of finding out.

The third is for my profile and the assessment of the recruiter to work together to encourage the hiring manager to grant me an interview. My impression is that my portfolio is not effective in this third step.

Revamping my design portfolio: audiences

The questions raised here include

  • Is LinkedIn a good way to get my profile in front of recruiters?
  • Does my resume do a good job of getting the recruiter to pass my profile on to the hiring manager?
  • Does my portfolio do a good job of getting the recruiter to pass my profile on to the hiring manager?

But of course these are not the sorts of questions I can usefully ask directly; the likely answers (yes or no) wouldn’t improve my understanding much or help me make changes. Instead, I should ask questions that will help me gauge the effectiveness of what I have, provide details that may lead me toward changes, and identify what is already working. These questions will look more like

  • Which of my assumptions are off base? (with a list of these assumptions)
  • For the position in question, did you have any misgivings about my profile, other than location?
  • What seemed most relevant about my profile?
  • What seemed to be missing?
  • Did you review my portfolio?

This sort of question will ideally not be too much to answer, and spark a little conversation that will help me know what to keep or play up in my profile, what to give more emphasis, and where I’ve left gaps. But first I must get them to engage, so I’ll contact them via LinkedIn with a simple message:

Hi, [name]. I’ve decided to turn my design research powers on my portfolio and resume. I’d love to ask you a few questions, since we recently discussed a position. If you are willing, I promise to make it easy and not take up too much of your time. Yes? Thanks, —Jon

Next up: understanding the results.