In late 2022 I gave a presentation to the hiring committee at Invoca in lieu of a portfolio review, a sensible adaptation when hiring design leaders who aren’t likely to have recent personally-crafted portfolio pieces. And it worked! They hired me right away.
There are a lot of slides, but much of this presentation is meant to be fast-paces, a few seconds per slide (or less than a second in some cases).
Page 1: I’m Jon PlummerPage 2: I’m a design and research leader with an academic background in psychology, anthropology, and social workPage 3: And I have many hobbies lightly held, including but not limited to home improvement, cooking, jazz piano, RV camping, and all manner of tinkering. I also have a wife and daughter who like to travel; here they are swinging on swings in the old botanical gardens in Munich in 2018.Page 4: By the end of this presentation I hope you’ll know: A little about my past experience; A bit more about my leadership style and how that works; And understand some examples of that style in action.Page 5: I finished grad school with a master of social work, realized I was hungry and licensure was years away, and began a design career just in time for the dot com boom to begin.Page 6: I came up through report design, web design and front-end coding, web apps, medical software, medical devices, and consumer electronics and software.Page 7: I recently led UX design and research at Cayuse, a research management software as a service provider. Main challenges there included: bringing disparate acquired apps together into a suite, improving the accessibility of products, helping the org move from more sales-led to more product-led by raising the level of product team knowledge about customers and users, and pushing the org to make better use of user data such as basic user success metrics, support contact data, NPS comments, etc.Page 8: Prior to that I was Director of UX for a small software development agency here in Eugene, serving mostly educational clients. But a lot of my understanding of design management I learned at Belkin. I’ve been refining my methods in different environments and with different types of work ever since.Page 9: At Belkin I led the product experience teams for Linksys and Wemo, working closely with the various product and program managers, firmware and software engineers, etc. to marry physical and digital experiences to make products easier to use, cost less to support, and get better reviews and higher ratings. And supporting UX and UI designers, researchers, industrial design, mechanical engineering, beta testing, and a design program manager. So we worked on everything from getting your new device out of the box, having the right parts fall to hand, getting the necessary software, setting up the device physically and digitally, enjoying your first use of it, using it day-to-day, and troubleshooting when there was an issue.Page 10: While at Belkin I institutionalized regularly-scheduled usability testing…Page 11: and in-person formative research, and reinvigorated the beta testing program…Page 12: revamped Belkin router setup, enhancing customer success and cutting support costs markedly…Page 13: filed for over twenty patents in networking and IoT…Page 14: worked to fill in numerous gaps in brand, strategy, and roadmap…Page 15: begun the development and adoption of design systems for the Linksys and Wemo apps (WIP)…Page 16: and raised Linksys app ratings from 2.2 stars to 4.7 stars, and Wemo app ratings from 3.1 to 4.4 stars. All of this reflects me adapting processes and the org to produce better products, developing designers, and adapting to the needs of disparate groups in the larger team while fostering change at whatever scale necessary.Page 17: The other day Anna or Nicole asked me what my leadership style is, and I blurted out “supportive.” That’s part of the story. I don’t really talk about people as “my employees” or “people who report to me” – I like to think of designers and researchers and writers etc. as “the people I support.” The people commonly thought of as individual contributors are the hands and feet of the organization, doing the actual work that our users and customers will interact with, and they need the path cleared to do their work as best they can.Page 18: I typically have a weekly 1:1 with each person I support, time specifically set aside for me to support them. And I try to create the conditions for the people I support to be mutually supportive as well.Page 19: One way this occurs is by having weekly design critique, prefaced by my giving the team whatever “news” I’ve gathered from the org. Here’s a training I gave at Concentric Sky about critique and what it is and is not. Critique is not about design approval; it’s really time to borrow the brains of other team members for help working on whatever you are working on, and the teams where I’ve put it in to practice have, over time, come to seek each others support outside of critique, have been more aware of what is going on on other teams, have borrowed good thinking from each other, and have in general started to converge in terms of the experiences they are producing. This works remote or in-person; at Cayuse most of the folks on the team had never met in person.A good design system and pattern library helps with this too, of course, and while someone should be in charge of it, it’s worthwhile to have multiple individuals chew on it and take pieces to work on.Page 20: In order to improve our results we need to change our behavior. “Try harder” is not typically an effective strategy. There are a great many ways we might need to adapt.Page 21: We might need to add capabilities by bringing in people who have these capabilities, or through training. We might need to encourage existing behaviors through process changes, internal metrics, or incentives. We might need to change which people work together when. We might need to address specific interpersonal issues. When something isn’t going quite right my first questions are not about who, but what is our goal and what activities are contributing to that goal or detracting from it.When I arrived at Cayuse, several product managers largely gathered feedback from customer advisory boards, and many on those customer advisory boards were not frequent users. Some weren’t users at all. And the designers basically punched out UI based on very specifically-written stories with little or no user contact.Page 22: Both designers and PMs needed to be pushed toward alternate research methods, especially user interviews, so I pointed out what sorts of activities went with what parts of the Cayuse process…Page 23: and gave trainings on interviewing intended to lower the barriers to actually doing interviews. Here’s how to plan, here’s how to schedule, here’s what to do in awkward situations, etc. And it worked! In the Risk Management, Inventions, and Animal Procurement teams that were only doing CABs, they started doing interviews to investigate specific capabilities they were working on, leading to more meaningful debate and decisions that could actually be explained to upper management.Page 24: We also might need to adapt when it comes to the data we seek – Belkin and Cayuse both neglected support contacts for a while. Cayuse is still wrestling with how best to use NPS comments, and for now ignoring customer forum discussions as a data source. Some orgs look for “North Star” metrics when they really should start by counting basic user successes.Page 25: I’m also a little bit skeptical of “best practices” – when people speak of “best practices” it sounds to me a lot like copying. Being informed by what others have done, and experimenting, piloting, adapting, is great. But if you just copy you’re not learning.Page 26: I debated whether to call this “communicative” or “connective” – to be most effective, people need to to know what’s going on in the organization, how their work contributes to the success of the product they’re working on and the org as a whole, and why we are making the decisions we are making. They need to be plugged into feedback and data coming from real users and real customers. They won’t act in an empowered and accountable way until they are able to make decisions, however small, in an informed way. That’s why critique starts with the news, for example.Page 27: I’m fond of a “one page strategic plan” approach to ensuring that our adaptations are chosen to support our goals and our strategy, and I share this thinking and let people help with it. This is an example of a one-page strat plan from Belkin days, too small to read, where each strategic objective is broken down further and further until we get to concrete activities. Generally you’ll find that some activities feed multiple objectives and are thus especially valuable.The important part here is not that this diagram looks wooly or complex – it’s that by going through this exercise we can arrive at a prioritized set of initiatives to improve how we work and the quality of that work, arriving at that plan is done in public, and the plan is available for review so that when we aren’t thinking straight we can recall what we were thinking when we were thinking straight.Page 28: It’s essential that the people needed to make a decision get together to make the decision. There are many forms of “get together” but I’m especially fond of product trio, where the key product person, key technical person, and key design person make decisions together. If push comes to shove the product person owns the product, but the main idea is to avoid ill-informed decisions that invite revisiting immediately. I can’t tell you how many times a designer has come to me complaining that “the plan changed again” when the underlying issue was that the right people were not together, leading to an unstable decision, or an opinion being taken as a decision.Page 29: I like to evaluate design in terms of themes, and to make sure we are all aware of and supportive of these themes. These are experience quality themes from Cayuse. Invoca might have different themes.Page 30: It’s also essential that in general we communicate in terms of goals rather than just instructions. I try to model this whenever I can. Instructions describe one way to meet a goal. It’s helpful to know what we are doing, but it’s essential to know WHY as we will need to adjust at some point and it’s easy to choose the wrong adjustment if you don’t have the goal firmly in mind.Page 31: There are good places and bad places to innovate. But what do we mean by innovation?Page 32: I like the IDEO definition, which is simply “introducing new ideas.”Page 33: In general, I think we do NOT want to innovate in interface design. We want to make something understandable, usable, useful, informative, branded, and pleasant. People learn about how software works by using software. Thousands of hours of other people’s software. We don’t need to be boring but we do need to be familiar.We may want to innovate as we improve our processes. It’s good to be informed by what has worked elsewhere, but let’s not copy from others, let’s learn from others and adapt. I DO think we need to innovate when we are exploring, thinking about how to solve a problem, coming up with concepts. And we especially need to introduce new ideas when a concept is too clever or fancy to be cost-effective.Page 34: We can think of our interventions on a scale from the simplest thing that could possibly work to too fancy for the ROI, and the right concept for today is somewhere on that scale, often a little lower than we’d expect. We may need to introduce new ideas to make something satisfying and effective that takes us down that scale to the right level.Page 35: Two quick cases from Cayuse – the first illustrates the difference between a user-uninformed feature and the same feature made more usable and appealing through direct research and user feedback.The tech transfer office at a university licenses the universities’ inventors’ technologies to companies and receives royalty payments in return. When those checks come in, the money needs to be distributed according to the terms of the licensing agreement and an internal technology agreement and university policy. Typically very complex excel spreadsheets are made to accomplish this, and there’s nothing automatic about the process.Prior to being acquired by Cayuse, the inventions product people designed a system to make distribution templates – arrange the distribution rules, put money in at the top, and see where how much of it should go. How much for the inventors, how much for the department, how much for the university, etc.But their system was very cumbersome to use, and easy to get wrong. Some of it was just basics – when you added an item to the template it went to the bottom and you had to click these little arrows a million times to move the item into the right place. And every step along the way the location of that item was potentially wrong, or even potentially an error.The inventions team had sold their product to eight universities, but no one would use this part of the system. It was too annoying.Page 36: Before leaping in, though, we needed to understand how these distribution templates actually worked, and which of many possible usability issues the customers were most harmed by. The acquired founder of this product knew two key customers and they each put us in touch with a few people in their tech transfer offices.These people had previously tried the feature, thrown up their hands, and abandoned it. Their Excel spreadsheets, while cumbersome, were familiar and malleable.Page 37: Showing the existing feature to them and talking about how it worked revealed a few main issues to tackle: All the clicking; Adding only at the bottom; Easy to get indentation wrong; Confusing labeling and modes. Plus some dumb things like controls at the top, action at the bottom. So we have some problems to go after!Page 38: So let’s let you add an item where it should go on the template rather than just at the bottom. We’ll make things only go where the nesting can be correct. Let’s allow, but not depend on, drag and drop. We’ll keep the construction controls static so you don’t have to hunt for them.Page 39: And let’s guide your action through labeling and clear nesting. Just these changes, tested in a Figma prototype with those same users, got them enthusiastic about trying the feature again.The result is a less flexible interface, but one that is less prone to error, as we’ve lopped off a raft of opportunities for mistakes. The nesting is clearer. We can let you move things around, but you can’t put them in patently wrong places. And it takes much fewer operations, fewer clicks or drags, to make these changes.The engineering team (of two) was initially reluctant – they weren’t familiar with the Cayuse design system that these controls were based on. But they were happy with the work we had done to make implementing the common header straightforward, and one of them was present in some of the discussions with users where we tested these ideas in wireframe form, so the functionality was an easy sell; it was merely a matter of their comfort implementing it.During our discussions with users we learned also that they expect the system to know, for a given technology, who the inventors are, which departments, etc. They shouldn’t have to fill all that out. And the system does have that data. So, when it comes time to apply one of these templates, we should be able to pull in things the system already knows and not make you re-enter them. The job of data entry could become merely looking it over to see that it’s right. So this project usefully fed the roadmap as well.A lightweight improvement that’s now sensible, is to look at the most common distribution templates our customers need and to see if we can ship with some of these as templates already built, further reducing the work it takes to get started. Rather than making something from scratch you can start with something close to right, and bend it to your needs. So we’re uncovering lightweight and deferrable but potentially powerful enhancements as well.Work of the designer and an engineer directly with some key customer users unlocked these possibilities.Page 40: That was a quick one. The next one is also from Cayuse, but it’s genesis is in some work Concentric Sky did for Western Governors University.WGU needed an internal too to help them manage Rich Skill Descriptors. They would research these skills and manage them in a massive Excel spreadsheet. It was hard to find duplicates, they had to make copies to gather the skills into collections to share them with curriculum developers, updating and obsoleting skills was difficult, and their work could not be shared with other institutions. They also had a few scary mishaps where they thought they had lost a year’s worth of work.The tool needed was quite straightforward but we had only about four months to research, design, develop, and import their existing data. And we had already spent a solid third of that making sure we knew just what they needed.Ordinarily as part of our regular delivery, Concentric Sky would make a design system or perhaps a pattern library as part of finishing up work for a client. That way they could make better use of our work, and if we came to work on a later version of the project we could use it ourselves.This skill management tool was small enough in scope and enough in a hurry that I saw an opportunity to create a design system early and use it to deliver detailed designs, with good behavioral notations, and get at least the front-end engineering done more quickly. And with the agreement of the FED on the project, we gave it a try.Page 41: With our research-backed prose description of the major functions of the application in hand we made loose wires for the entire project, ran these by the client, who was also the user, and then scoured these for common elements. The hope was that we could settle on a finite number of components, document these, and speed development along by reducing uncertainty about things that, ultimately, were important to fit and finish but not the underlying requirements, which were pretty well-understood.The interesting part of all of this is not the visual artifact of the design system itself…Page 42: it’s a document, titled Acceptance Criteria for Patterns. It describes the use and behavior of each control in detail and links out to the relevant design assets. A basic page skeleton is also included to orient the reader.No one knew what I was talking about when I started to blather about maybe needing one of these. But it made sense to the UX designer and the FED once I got the document started. And while the front-end work proceeded, if there was a thing that needed to change due to an oversight or an issue during development, we could negotiate it and fix it once, at the pattern level.The skills management tool was simple enough that we could do this up front. It’s uncommon that that’s the case. But lessons here were valuable at Cayuse later.Page 43: Cayuse had around 20 apps, many of which were brought in via acquisition, with very little in terms of common design language, interaction, etc. There had been halting attempts in the past to rebrand a few of these, and even those that had this work done were drifting apart. It was clear that we needed a design system at the very least, better if we had a pattern library, and we needed to make sure that anything the design team delivered in the meantime helped the products converge rather than drift further.A design system requires care and feeding, someone needs to own it. I spoke to the CEO and the Directors of Product explaining my plan and its benefits and they agreed. The CEO immediately wanted a schedule! I negotiated some reallocation with the Directors of Product and put someone on the design system half-time. The first challenge was to make a design system that would support rapid and consistent delivery of detailed designs.Page 44: There’s a maturity model here, and we were pretty far at the left end, where there are some brand guidelines for Marketing, and some applications attempting to define styling, but these are inconsistent. We needed to make strides defining the components and delivering work using those components.And we needed engineering and QA to participate if we were to get very far down the maturity model.Page 45: So we gathered the best parts of the apps that had been worked on recently and started to codify and improve components. Building these in Figma for our reuse made delivering designs easier. Rather than find money for a specialized tool we put our documentation in Confluence, which we already had, and cross-linked with the Figma files.When we showed the architects and QA folks what we were doing, the QA folks loved it, but the architects raised an eyebrow. They felt engineering was “too busy for this.”You see, Cayuse was (and is still) laboring under once being a sales-led organization that sold too much of the future, and is working through a bubble of overdue customer commitments that seems to never get smaller. The architects felt that they would never finish this work if they added beginning and maintaining a pattern library to the engineering team’s workload. I have thoughts about this predicament that I won’t share here.But if you can’t sell it wholesale, maybe you can sell it retail?You might notice in the above a little section about accessibility. It was accessibility that finally started to open things up here.Page 46: When I arrived, Cayuse’s approach to accessibility was to ship software, have an outside firm audit it, receive a VPAT, enter the items on the VPAT as bugs, and maybe never get around to fixing all but the very worst ones. All the while, customers are complaining, as they have a statutory requirement to provide accessible tools to their employees, and all the while some of the same mistakes are being made repeatedly in this product or that product.Design system to the rescue.Page 47: The revised process was to collect the VPAT complaints as input to the design system, and explain the needed fixes at the pattern level. That way we could fix things en masse, if there was an en masse to fix, AND forestall the same mistake later. It turns out very few of our VPAT complaints were one offs. Many appeared in one form or another all over the applications. And testing some of the basics is automatable.And rather than go back to the architects with this plan, we started to do it, and explained what we were doing to the tech leads on individual product teams.They ate it up, as it made fixing the bugs that were filed more straightforward, and made preventing bugs more straightforward. They started to share code amongst themselves and across teams, where the technology would allow. So the beginnings of a pattern library started to emerge at the grass roots rather than top down.Page 48: That section about accessibility is still improving in a lot of components, but in the best ones it has links to specific VPAT complaints that are relevant to that component, recommendations and instructions, and links to authoritative web pages, such as the W3C’s Web Accessibility Authoring Guidelines, so that an interested developer can go as deep down the rabbit hole as necessary.Page 49: Before I left Cayuse we had gotten pretty far down the maturity model. Farther than the architects imagined, for sure.Page 50: Nathan mentioned three expectations of this presentation; let’s see if I addressed them.Topics already covered that help: critique and the cross-pollination that it fosters, design system and pattern library, process improvement, greater level of user knowledge, product trio, judicious innovation. Products are not in lockstep with one another, or cars in a train being pulled along behind the design system – the design system and PL are living items that are never truly finished and the products contribute to the design system as much as the other way around. But since teams are informed by each other’s thinking, borrowing solutions from each other, contributing to the pattern library, they behave like a school of fish, generally twisting and turning and progressing together.Another topic that hasn’t really been mentioned directly: the three horizons.Page 51: I tend to think of the UX team’s research and design work in three horizons.The nearest horizon, closest to launch, the stuff teams are consumed with most of the time at most companies, is detailed delivery. How exactly is it going to work, what exactly is it going to look like, supporting development and QA in delivering that, adapting to technical challenges that emerge. Tactical. And risky without a design system, without usability testing, and without doing a good job in other horizons. Call that the “detail” phase.The second horizon, a little further out from launch, is where we’re coming up with concepts to accomplish what we want to accomplish, evaluating those concepts, and selecting one to proceed with. We have a goal firmly in mind and quickly, cheaply discuss and bash together a few ways we might achieve that goal. Product is here, design is here, engineering is here, users are here. Each of these people has ideas, knows things we need to know, can help steer our thinking to good possibilities. Most orgs skip generating multiple concepts entirely and wonder why their results are dissatisfying. Call this the “concept” phase.The third horizon, farthest out from launch, is where we are trying to figure out what benefits to offer to our users and customers, what new behaviors we want to turn them on to, what new capabilities they need. Incoming data, summative usability testing, direct research, surveys, etc. all contribute to the signals we need to understand what benefits represent desirable opportunities. Call this the “benefit” phase.The nice thing is that we can scale the work in these phases up and down depending on the task at hand, how risky things are, how much we already know. None of these require us to be in the same place, just that we be on the same page. And it’s a fair bet that Invoca would like to get stronger in at least one of these phases. Which ones I can’t say from here.Page 52: If there are capabilities we need in order to accomplish a goal, we need to find or build those capabilities. It’s common that we will find there are multiple skills to improve, in which case we need to prioritize them based on what we need first for the strategy or roadmap or what’s going to have the greatest effect first. That’s where a one-page strat plan is helpful.Page 53: If it’s a matter of allocating capacity to projects, that’s primarily a negotiation with the product team and with Nathan. How does observed demand compare to observed capacity and what we expect from what’s next, and which of these things deserve the most care and feeding? If reallocating people in this way is painful, how much more do we need to relieve the pain? There isn’t really a system that you can put these things into that will feed you an answer, but a table that lists the initiatives, their priority, their allocation, what’s next, and where the need is greatest can be a help.Page 54: To me this is all about what’s in it for me for the various allied disciplines. For example, a more mature UX discipline can help raise the knowledge and influence of the product org through better connection to users and user data help the engineers produce higher initial quality through the de-risking of designs, involving engineering in concept generation and selection, and by steady improvement of the design system/pattern library in terms of style, behavior, accessibility, etc.help customer care by helping draw attention to and addressing the same stupid recurring problems, and reducing the likelihood of new ones help the organization as a whole deliver by offering concepts that are lower in complexity or effortBut we don’t do ANY of this by ourselves. None of this happens without greater connection between the groups, greater information-sharing, viewing each other as not just customers or necessary evils but as teammates.There’s a saying in volleyball – job one for each person on the court is to ”better the ball" – we do that by supporting each other as we attempt to support the user. A UX team barely betters the ball if it is busy taking “sandwich orders” punching out UI as fast as it can, and greatly improves the ball if it is helping the organization learn, develop concepts, choose among them, and deliver.Page 55: Questions, comments, observations?
