Love Letter to My Bootcamp

(We graduated from bootcamp today and I got to say a few words.)

Good afternoon—welcome friends and family.

Please raise your hand if you can confidently define what your loved one has been doing for the past 18 weeks.

…If you are here on behalf of a graduate and still not quite sure what black hole they have fallen into the past few months— it’s okay.

User Experience is simple and it is not simple.

It is flexibility married to complexity.

It is quantitative and it is qualitative.

It is how someone feels when they are interfacing with a system.

I want to share with you two of the greatest takeaways I have gotten from this program.

The first is simple—don’t procrastinate. Ever. Especially on Mondays.

The second is more complex—it is the difficulty of simplicity.

I have learned, from researching and wireframing and prototyping and user testing and presenting, —never to assume I know how to do anything.

Whatever I’m about to do is bound to take many more hours than I estimate. This humbles me every time—and it gives me a deeper respect for every aspect of other people’s work. It is difficult to make technology feel effortless—to make it feel simple.

Mark Weiser, the chief scientist at Xerox, said this:

“The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.”

Great design is simple, and research and empathy, and really hard work are what make design good for people. And that, after all, is why each of us is here. We want to make technology better for the people that use it.

So here we are.

We have learned to identify problem spaces, prototype solutions, and evaluate concepts. We have learned to ask for help and to give  and crave feedback and constructive criticism. We have learned to design for others, rather than for ourselves. We have learned that user error is usually the product of bad design.

And we have learned that there is always, always more to learn, and that the key to success is curiosity.

To our instructors—thank you for your dedication, feedback, late night help, shared tears, and inspiration. Thank you for being strong, smart women leaders in technology. Learning from you makes me feel like I can succeed in this male-dominated field. Representation matters.

To the support staff—thank you for supporting this group of people—for looking at us and thinking we might not just have what it takes—we might have more. We do not have traditional backgrounds. Thank you for helping us understand that this will make us better practitioners.

Collectively we have:

Raised our families

Raised other people’s families professionally

Studied religion and psychology and graphic design and human factors

Served our country in the Army

Been to prison

Reclaimed our lives

Owned our own small businesses

Healed Olympic athletes

Quit our jobs to travel

And dropped out of art school, twice.

Thank you for looking at us and recognizing that these experiences will inform our practices—that they make us stronger, more creative, more dedicated UX Designers.

Thank you for pushing us harder than we could have ever pushed ourselves.

To my cohort—I’m so grateful to have experienced this with each and every one of you.

Thank you.

post-its on the wall, ready to be organized


Design Strategy: Group Work, Scope Creep, and When to Throw UX Best Practices out the Window

I am a big proponent of being challenged as a catalyst for growth, but it can be, well…challenging.

The way this bootcamp training program is formatted is with a new case study, new skills, and new insane challenges each week. I’ve done four different case studies and I feel like I have come so far from where I started. That feels really, really good.

However, in week three I worked on a design strategy for a real-life UX client, which felt like something that was ludicrous to attempt when I had just learned what design strategy was on Monday–and I was supposed to meet the client on Tuesday.

It was hard both because of the nebulous nature of design strategy—from what I’ve read, it is a challenging effort even for UXers who have years of practice—and from a group-work perspective. I am also starting to feel the cumulative effects of multiple weeks of perpetual brain motion and the creeping realization that I am going to be searching for a job soon. These are all known factors and should not be surprising, but it’s quite different to be in something than to think about it abstractly.

That being said, I still think challenge is a good thing, and trying to think past the scope of the screen, attempting to engineer a life experience (such as relocating for work) in the context of a group has been eye-opening.

Make it. MSP. is a collaborative project of makers groups and community members who love the MSP region, and is an initiative of Greater MSP (an economic development partnership in the region).

Their mission is improve the net migration of professional technology talent in the MSP region; that is, to attract and retain tech talent. Research shows that tech talent moves here, but they don’t stay–this is particularly true for tech professionals of color.

When given the Make it. MSP. project, our group had several fun, viable ideas (perhaps more viable than the one we ended up going with), and it felt really good to be generating them together. Collaboration is so useful when you are coming up with ideas and solutions, and we came up with so many ideas that our midweek critique had a clear message—we were getting into scope-creep territory and needed to rein it in a bit—our strategic design model couldn’t just be “design all the things!”

So, this was where we started to get a bit stuck—we had all put a lot of work into the different elements of the presentation by that point (research, deliverables, and content layout) and it was tough to advocate for deleting someone else’s content. We were also all editing the same presentation file at the same time and operating with different stylistic approaches and different priorities in a way that was not 100% complimentary. A few weeks back at the UXPA MN talk I saw a quote by Dr. Linus Pauling that said “the way to get good ideas is to get lots of ideas and throw away the bad ones.” But what if you throw away the good ones and get yourself stuck with the bad ones?

Just Ask the Stakeholders

Robert Hoekman on uxpin talks in his article “The 11 Minute Guide to Bulletproof UX Strategy” about scope and keeping stakeholders in mind: “When they give you answers about the product’s purpose, scope, users, competitors, and so on, these answers are driven by financial concerns. So when you make recommendations later on, be sure to couch them in discussions about what percentages of users do generally or are doing in this case, and with regard to how a decision affects the product’s ability to make money.”

We didn’t do this exactly (at all), but it stands in favor of narrowing scope appropriately. It’s tough when you are working partially within the confines of reality: the concept we came up with was going to be shown to a real client who might really take it and run, but it’s still not the same as being hired to actually solve a problem. I’m not sure if we hit the mark with our project or completely missed (or somewhere in between)—we definitely went a bit into the stratosphere with our idea–a Make it. HOME. housing complex that is similar the to artists’ loft housing in the Twin Cities, but for tech professionals.

Which seems like a great idea, except for the money part.

Getting Out of Your Design Comfort Zone

I read an article on Adaptive Path recently about kind of the opposite idea: discomfort and tackling ideas bigger than you’re used to (widening scope). It’s by Nick Crampton and is titled Designing Out of Your Comfort Zone.

The author is talking about a similarly lofty UX challenge: improving the service model for GLIDE, a San Francisco organization that provides basic needs services. Many of their clients are homeless, drug users, and/or recently getting out of prison. Their most visible service is their meal program, and the project was aiming to increase the visibility of their healthcare, housing, childcare, crisis management, violence intervention and education services. The author was challenged in his process in bigger ways than, for example, a usability test of a website.

So it felt a bit like our project.

He writes about the best practices for UX such as formalities, protocol, length of interview time, and recording of interviews—and how inappropriate that felt when building trust with marginalized clients of GLIDE. “Best practices and protocols are great for approaching problems in a proven and consistent way, but it’s important to acknowledge when something just doesn’t feel right for the context you’re designing within.” This seems to me deeply rooted in empathy—understanding what might be inappropriate or even voyeuristic, opportunistic, or unethical.

In a more clinical setting, with self-selecting participants testing an app, this is may be less of a concern, but with strategic design for experiences, you are in some cases working with real, bigger issues.

Big Real Shit

Part of the hugeness of this week was the specification that Make it. MSP. was aiming to battle Minnesota’s diversity issues—professionals of color come to Minnesota at higher levels than other groups, but they don’t stay; big issues include the lack of cultural awareness and overt as well as subtle discrimination in and out of the workplace. Racism in the United States is an insanely complex, deeply historical issue, and really pertinent right now within the context of US politics. Let me rephrase that: it’s always pertinent, but lots of white people are thinking about systemic racism more than they were a year ago.

I’m interested in the work Make it. MSP. is doing to battle that ocean (it’s really important work, and people’s lives literally depend on it in some cases), and their attempts to increase cultural awareness, and start to change the tide. But in our classroom, and without much time to think about bigger implications, and without a diverse cultural representation in our classroom, most of our solutions felt tone-deaf or insensitive and I think it’s dangerous to get into attempting to try and tackle an issue like racial inequality without the greater framework of social justice.


Back to the Article, Collaboration & Curiosity

Crampton says, “being in unfamiliar territory can feel paralyzing. But one of the first steps is identifying who your guides are and what they can teach you. The beauty of design is that you don’t have to come in with all the answers–nor do you necessarily have to end up with all of them,–you just have to know how to ask the right questions and how to get others to help point your team in the right direction.”

“Aside from our discovery and research phases, and our close working relationship with the staff at GLIDE, which were huge learning opportunities, we knew it would be foolish to try and build out a full-fledged service, launch it cold, and then hope it hits the mark.”

What he is talking about here is service pilots as a part of the process of iterative design—this is huge. Having worked in nonprofits, which are often high-stakes and low-money situations, this is a big deal. He also says “don’t agonize over getting it right the first time.” I have said before that the concept that you literally cannot get design right the first time is freeing, and I think that is particularly true in this context. However, if you get stuck in “this is how we’ve always done it” territory, or if your employees are so burned out and overworked that they can’t think to next week, never mind long-term strategically, it’s important to get kind of close on your first try.

“We took everything we had learned, co-created some service concepts with our core team at GLIDE, refined those into a narrative that felt right and then built a lightweight service to test our hypotheses. We built in ways to gather feedback and capture opportunities to improve the service before it was fully rolled out.”

I think I liked this article because it is 95% about the process, not the product, which is the essential core of UX writing. And I love the closing words of the article: “So yes, trust the process. Until you can’t. Then dig deep into what you believe your values as a designer are and seek to understand who you’re designing for.”

So, who are you designing for?


(Note: I’m posting my full projects on my portfolio at and should have the two platforms integrated soon. For now feel free to check them out!)

On UX Design/Dev Relationships, Impostor Syndrome and the Urgency of Teamwork (UX Bootcamp Week 1)

Gosh, it’s been an interesting few months. I worked my last day at my nonprofit job two weeks ago and started at an accelerated tech learning program for User Experience Design (UX). When my head isn’t actively exploding from all the learning, I’ll write more about that decision, what brought me there, and about what UX is. But not today. Today I want to share some reflections, and we can back up later.

Last week was my second week of full time UX Design Bootcamp—and I survived.

In the first week, we talked about a broad range of subjects, from usability testing methods to heuristic analysis to the cultivation of empathy to impostor syndrome. I collected a few articles on things we discussed in class that piqued my interest in some way and I want to talk a little bit about them.

Everyone is a Designer, Get Over It by Daniel Burka

The writer here is asserting that all members of any company team are UX designers to some extent, which I think is possible in the sense that many decisions they make will affect the user.

Whether you like it or not, whether you approve it or not, people outside of your design team are making significant design choices that affect your customers in important ways. They are designing your product. They are designers.”

But that certainly doesn’t mean that UX is irrelevant—in fact, it seems like it means quite the opposite. UXers are strategists that connect the dots—from products and marketing to the back-end code of a site—UX Designers are advocates for the people that rarely have a voice in the organizational arena: the users.

Peter, a reader responding to the article, said: “Apply this idea to where you fit into an organization — it isn’t a unique trait to Designers. It doesn’t make you a designer, but it will make you really successful at what you do. A user-centered Marketer, a user-center[ed] Engineer, a user-center[ed] Product Manager, etc.”

Does design lie in intent? That is, if someone makes a decision that affects the user’s experience are they an experience designer or an experience “affect-er”?

Does it even matter?

I’m honestly not sure why this was the article I chose to start with—it seems like the semantics of design is maybe biting off more than I can chew at this super-newbie stage. However, the fact that members of non-UX teams affect the user’s experience is obvious.

Burka also talks about the design team’s responsibility to reach out to the other teams—that the best user experience will come from that communication and collaboration. Regardless of whose responsibility it is to begin that conversation, that’s an important point. He says, “The reality is that other people are making design decisions with or without you. Embrace them. They don’t make your job less valuable. They don’t make your job title less meaningful. Having more people who do design is additive, not competitive.”

What I like about this idea is that all work has a collaborative element to it and that teams are deeply connected to each other whether they embrace that or not. None of us exists in a vacuum.

What is a bit scary is that, from what I’ve heard from my mentors and other experienced UX practitioners, UX still has to defend itself in a lot of organizations. It seems like UXers in certain companies have to state their value and defend it on a regular basis.

So…what if I’m not good at my work? Or more deeply concerning, what if my work is not even important?

That brings me to the week’s next idea.

How Experienced UX Designers Manage Imposter Syndrome by Leigh Gamon

Ah, impostor syndrome.

It’s the embodiment of the aphorism “you are your own worst critic.” It can suck the life out of you if you let it. The author states that professionals at all different levels of UX background feel it—it ebbs and flows, but never truly disappears.

That’s a crummy thing to think about, but here’s my takeaway: if even the experienced professionals feel it, don’t give that voice too much of a seat at the table. Sure, listen to your gut, generally speaking. If you truly suspect you are wrong, reassess and find the right answer. And obviously, don’t come in as a Junior UX Designer and think you’re the first person to invent, say, empathy. Just don’t allow imposter syndrome creep in and take away your confidence when you are right, when you do have a good idea, when you did a good job with the tools that you had.

Here’s the paradox: the author states that the worst case scenario when you’re facing impostor syndrome is someone telling you you’re wrong. However, that humility will be a positive driving factor in your work. You will continue to work to improve—and then your answers will be more steady and sure.

I’d like to add that it falls in line with any criticism or feedback—if someone tells you you’re wrong, and you genuinely are wrong, that’s a gift. A shitty gift, but a gift nonetheless. Now you have something to work on: you’re welcome.

Now, we obviously want to know when we’re wrong, and there are different ways people can convey that to us. If you communicate only by email and never meet anyone and someone doesn’t know you, they are more likely to go above your head and talk with your boss if you are wrong. Now, if they know you and trust you, they are more likely to approach you directly and talk about their concerns and issues.

Gamon states, “Easily my favourite piece of advice I’ve received (and arguably my own personal mantra), is that relationships are the key to thriving in new situations.”

I’m going to place an emphatic YES on that one. Teamwork is insanely important. Ask any third grader (or writer of motivational posters).

Let’s talk about teamwork.

UX Design is Team Work by Ruben Bos

The author here is talking essentially about the shift from Waterfall to Agile method design. Rather than a project being handed off when one department is done with it, also known as “throwing it over the fence,” the entirety of a project’s lifespan is collaborative and iterative.

As a newbie to UX, that’s the only way I have learned. (Much like younger people who have only ever been alive with the internet. They have no true conception of what life was like without it—I’m part of the last generation to not have their entire awkward teenage years publicly displayed and immortalized on facebook, for which I’m very grateful… but I digress. Waterfall is to Agile what “no internet” is to internet. Or something. Give me a break, I’m new at this.)

Bos states that Agile is this idea that you don’t have to, and in fact can’t grasp the whole product in advance. Which is incredibly freeing. 

One of the best things that happened to me in the first week (well…aside from the huge life change and the beginning of a new, exciting career) was a lunch conversation I had about teamwork with some of the developers at school on Friday.

Let’s stop for a second and back up to day 1: I had been struggling to explain UX to a different group of development (dev) students, and what I discovered was that the way I had been explaining UX to my non-industry friends and family didn’t work in this context. I had tried to explain it as UX being the central bridge, the link that translates between devs, users and clients. As in, UX is the glue that holds it all together. And I have to be honest with you, that sounded icky to say to a developer. Arrogant. Kind of dumb.

So what is my role then? I know UX is important. How do I talk about it?

By that Friday, when I had increased my knowledge of UX by approximately one billion percent, I explained it to my new lunch buddies like this: “I am a tool in your developing toolbox*; I get to help you make your product better.”

And here was the part that blew me away: one of the developers called dibs on me for future collaborative work. It honestly was the proudest moment of my week— I felt I had arrived at a place where I could speak coherently about what UX is and feel confident in my answer. Who knows, perhaps in a year I’ll discover I’m terribly wrong, but it’s the best metaphor I have right now and dammit, I’m proud of it.

And if I’m wrong, I can’t wait to find out why so I can get better at what I do.

(Me at school)


*(Note to self: never start a sentence with “ I am a tool” in a professional setting again. Full stop). 🙂