This is a conversation that started on Telegram by @sarahmills, I'm capturing it and pasting everything here and we can continue the talk...
@sarahmills > Ok, I honestly hope no one remembers this conversation here from a while ago, but I can't help myself https://twitter.com/mulegirl/status/1119363337349787648?s=19
@qnou > Still don’t get how people logically reconcile the simple fact of an organization that employs 132,000+ people being able to make decisions without implementing stringent processes for testing and research. Would kill for that level of autonomy and ease of co-ordination over a job function.
I’ve pushed back so much in my life against gut feelings. If Product really believes in an idea, then they need to utilize Design properly to get data-informed results. “I feel that...”, “My hunch is...”, etc. are fine for prototypes but have no place iterating on live projects that have active users. Your customers will tell you what they want! Not just through surveys, but through Usability testing, DAU/MAU, etc
A problem I am STILL having to deal with and I am struggling to understand the psychology of someone who's like "no thanks I'm good" when we're like "would you like to be more sure about your assumptions before you spend all this time coding?"
Software engineers tend to think in verification (building the thing RIGHT) instead of validation (building the RIGHT thing). Both are important, but perhaps validation moreso... if a team spends 6 months building a cool feature that customers actually don’t care about, well ain’t that a shame I personally think that a large part of Design is educating Engineers on these concepts... it can be tough tho as engineers tend to think they know it all LOL and I say that as a current software engineer
I see it as a failing on my part...but I can't figure out what the magic words are, or how to be more persuasive. I've heard "how would you like to throw away less code" works, but some people tell me I should just let people fail/figure it out on their own. I'm not an overly confident person, so "let's double check this/let's validate" really speaks to me, but for those who are really confident (which I think is necessary in start-ups), I don't know how to get through to them
It’s a difficult discussion but I think framing the convo around timeframes is the way to go i.e. if we spend a week or two up front to guide the roadmap, we could save months (or years!) down the line. However, at the end of the day the other side of the convo has to be participating in “good faith” for this to succeed. that is, they have to be open to different options. And what I’ve found through experience is that it’s unfortunately too often that folks aren’t open to actually iterating on process, for whatever reasons I’m definitely working on my approach here and am open to suggestions! I’ve currently been working on a lighter touch and having folks come to their own conclusions... but guiding them towards what I think is right, like Inception.
This is by no means a magical key, but I've experienced these 2 approaches to be most effective:
* Go ahead and organize field research and invite people to join, 1 by 1, in person
* Stick to a narrow frame of testing the usability (building it right), any pre- or post interview allows to go into building the right thing.
Both have in common: avoid the conversation and meet people where they are. Experiencing research is thousand times more effective than any conversation which only creates a negative association with research altogether.
...I built this team originally around IBM design thinking stuff since that vocabulary was what I was most comfortable with and really works for enterprise, but after January last year broadened it out (a lot of the facilitators had experience with lean, Google sprints, and that other popular one that I forget). Now it case by case. We did find that having a pod of a DT facilitator, researcher, and a product designer did better than a single advisor or embedded designer alone. Additionally, people like @mentapurpura and others started adding game aspects to DT for mechanism design. I agree @hester, I would definitely use this approach if it was a single, or related suite of, product In Dec 2017 we had our 4 infrastructure teams do a workshop with the users right there, devs doing research. It's hard to ignore when it's right there in your face 🤣 and I think it had a big impact.
I was following your conversation and noticed you mentioned struggling about convincing the stakeholders or the team that research is important, as opposed to "going with the gut feeling", as well as participating in the process so they better understand the prurpose and the outcome. Did I get that right? I think you already answered my question Sarah, I'm advocating for design sprints.
Not very helpful probably, but I’d say gut, brain, research, data-driven, data-informed, etc are all valid and it really depends on your context what the best mix of approaches is to get desired results.
I'm totally with you Marko, the issue I run into is even getting to that point. I hate for all the wasted work (and money!) up until they come to my team wanting a "UI" and we have to walk them back. I just need to do a better job evangelizing as usual, but it's always been hard for me to empathize and have good messaging when I feel like it's the most obvious thing in the world.
It took a while for me to figure this out but one technique I started using is designing a quick and sleek UI devs/stakeholders think they want, test it out, then show them how and where the product failed - they tend to back off after and let me go through my process.
Can you tell me more about "selling" it within your organization? What's worked well in the past for you? My usual tricks aren't as easy in a remote org rn
I feel like the design community has this convo over and over, and by now we shouldn't have to sell it anymore...nobody has to sell development you know? Don't get me wrong, design in blockchain is like one million times better than it was 3 years ago
I'm also in remote org I agree, we're not supposte to be selling it but one of our skills should be the ability to "sell" our work or processes.
and I'm not referring to only Blockchain design, I'm currently workin in a consultancy that works on all type of projects
seeing the same thing everywhere
True. Also! It's really honestly only one team that has me down right now, so many others have come so far. @Nguyetv has been so heads down lately, today I looked at https://registry.civil.co/registry/in-progress/under-challenge and couldn't believe the engagement.
I'm talking with many UX peeps in agencies and consultancies around the globe and everyone talks the same. Unless you're truly design driven (from the founders) or have stongly decided and shifted to become design driven (in a true sense of that term) then I guess there'll always be that strugle to justify the UX process. I'll close this for now by saying "it all depends"
My experience has been overall good. There has mostly been an appreciation for design even if the processes were a bit lacking still. But I agree that it really depends on what type of environment you’re coming into and what the minds at the top value most.
I’m gonna chime in and guess that the prevailing lack of awareness/prioritisation around research could stem from how we define success in terms of product, and what the targets are for stakeholders. In a startup the qualification of the core idea would come before the first round. There has to be an element of survivorship bias amongst founders who think they’ve got a solid idea and process, when in fact they struck a good idea which somebody else could’ve reached through research. They demonstrate a market for that idea, and from then on out it’s an iterative process where they’re honing in on executing their solution. There might not be a research framework in here, but they’re going to be data driven and quantitative — especially given early-stage startups’ focus on growth. To simplify: why think, ask questions, or introduce the potential for subjectivity when you can instead test 47 shades of blue and demonstrate an increase in conversions, which you can take to your next round?
This process probably exposes them to other problem spaces albeit in a very passive manner. If that team wants to launch a new product in another area — they’d be confronted with the need for research proper. I think this explains what I’m trying to get at, albeit framed in a way I don’t necessarily agree with: https://mobile.twitter.com/tranhelen/status/1119035212141297664
A ‘leap of faith’ in this situation — when you have something to lose — should be a calculated decision based on a person’s needs. Further research & iterative design hone in on that solution and would likely be much more research driven.
I really like notion, but I’m also very aware that they struck gold with an idea that solved their own problems. Importantly — they aren’t focused on growth, and I suspect that they’re building out ideas as experiments, which isn’t necessarily bad when you’re building a product for yourself. But it’d be reckless to forget that for every 1 notion team there are countless other teams that misunderstood the problem space & so failed, and that taking their current process to another problem space would be reckless.
I don’t know how to communicate this to a lot of people, & I’m absolutely not a researcher, but I feel like they perceive research time as dead time which could be spent making small changes and (hopefully) measuring the outcomes. A part of this problem stems from a dogmatic approach to agile — everything is a 2 week experiment where teams have to deliver value. I feel like this is why larger organisations (or at least the ones I’ve worked with) have clear divisions between strategy/ux/UI/dev. They need to erect those barriers because having everybody in one team muddies the water. Strategy needs to get ahead of UX to feed things into UI, etc. Research, IMO, should sit in a separate workstream to the product itself and acting on the outcomes should always take priority when it comes to design + build. But I may be misunderstanding things.
Speaking of acting only on quantitative data you get via people interacting with your product, remember the grid?
Oh! And lets not forget that designers are complicit in the devaluing of research, especially if you treat product as a visual discipline rather than an engineering? psychological? sociological? one. I love graphic design, but people really need to get out of their own head and acknowledge that design (especially visual) is an artefact of surroundings; we could say that a style is a meme that became associated with ideals. To say that designing a product is the job of a 'creative' — even on the visual level — is woefully misunderstanding what a product is. Case in point: https://designcensus.org/. I couldn't find the button to take the survey on my laptop, nice one AIGA. I'm gonna stop now because think I'm starting to vent my issues with the design industry as a whole
Let's continue from here on, comment below