Design Strategy: Group Work, Scope Creep, and When To Throw UX Best Practices Out the Window
(May 21, 2017)
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.
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?