Vincit Dev Talk

Editor's Notes

• #2: How many people in this room are developers? Who are designers? Who work with designers? Who collaborates super great? Who eh, could be better? Who terrible? Ok… My goal will be to offend both groups equally tonight.
• #3: My name is Audrey Crane. I’m going to hopefully check off the credibility box pretty quickly here, even though I’m a designer. I’ve been in tech for a long time, since the olden days.
• #4: I wrote my first software when I was 5, on a trash-80.
• #5: I studied pure mathematics in college and my favorite course was non-Euclidean geometry. My favorite postulate is Euclid’s 5th.
• #6: And I worked at Netscape from 1995-1999. Ok? Credible?
• #7: I work with 4 partners at DesignMap…
• #8: …in San Francisco. We provide design services for our clients like these…
• #9: We specialize in designing software that could be complex but doesn’t have to be.
• #10: And we have a tightly integrated front-end dev team. We also partner very closely with our clients front- and back-end, as you can imagine would be necessary to be successfully designing and building products like these.
• #11: In the spirit of sharing the spirit of the successful partners DM Designers have had with developers, Tonight I’m going to share
• #13: Docker has been a client of ours since 2014. We started working with them when houseplants outnumbered employees
• #14: (In fairness they had a loooot of plants)
• #19: Eager and optimistic, I started off my year-long stint at Docker working on a quick fix to their existing purchase flow. This primarily involved redesigning how the products and options are presented to potential consumers on their website. A pricing page sounds simple enough, right?! Well a couple of factors threw us off-course and the end result wasn’t as optimal as my eager self imagined.
• #20: We started with this crap. [CLICK] You can sort of sort out the pricing [CLICK] If you don’t get lost
• #21: And this one. Hopefully they don’t need something between Micro and Small ‘cause I don’t know that that is. The smidgen size? [CLICK] Perfectly clear, right? How could we NOT make it better? The scope of the mini project was that a) design and development needed to be done in a week, b) no backend change could be made (this was a crucial restriction) and c) work with the (known) messy product pricing structure.
• #22: So we design this. Pretty, right? Given that, what we ended up was a less than smooth experience and an admittedly broken interaction. The once-cool-idea-of-a-slider became a clunky control that had a mind of its own. Design got called out for it when it launched, but ultimately, the product owner and lack of integration with the backend development were also key factors to its success.
• #23: Marina’s story here
• #24: i had 4 PMs roadmap based on OKRs, but once things got into roadmap it was mostly the engineering team and me who would come up with engineering and design tasks based on that roadmap. So we’d literally sit down every week, go through roadmap, sync on status, pick the “next thing to do” and deconstruct it into dev and design tasks
• #25: From these two stories, four lessons. First, be there early.
• #26: This breakdown of levels or areas of design is from Peter Merholz’ book, org design for design orgs. As you can imagine, the innovation with the biggest impact happens higher up on the chain, in big picture and strategy.
• #27: The trick is, that stuff also happens first. Developers need to be there for that. Sunny: huge team of engineers in India, the designs she sent over were not coming back right. After a lot of frustration and finally an in person visit to India, it turns out that they had their own opinion of how it should be. They wanted input into the design process, and when they were finally able to participate earlier in the design discussions things started coming back according to spec.
• #28: So, why don’t engineers and designers work together sooner? I think one of two kinds reasons, none of them your “fault”.
• #29: The first is just tactical: a lot of times the designer doesn’t know to invite you Or you don’t know it’s happening, because you’re working on something else at the time Or someone is trying to “keep you safe”. What is the answer to this?
• #30: Beer! Solve tactical problems with beer. No, seriously. You guys need to be in cahoots. If you do nothing else because you came to this talk besides Slack a designer, any designer (like right now, hint hint) and invite them to have a beer I’ll consider this talk a huge success.
• #31: The second reason I’m going to call “discomfort reasons”. I’m sure you guys are familiar with the cone of uncertainty.
• #32: This is the idea that early in a project there is a lot of uncertainty, and over time it decreases until finally the product is released, which is the only time you know for certain what will be released
• #33: In school and in practice, designers (who aren’t any better than developers at dealing with uncertainty, that’s bullshit), are given tools for managing and taking advantage of uncertainty. Developers aren’t given these tools. They may feel physically uncomfortable in those situations. Ben Singer’s story. The answer?
• #34: It’s useful to note, that if you’re an engineer, and you write a bunch of code, and then there’s a change, you have to throw all your code away 99% of the time. As a designer, much of what you’ve done and learned remains relevant, especially earlier in the process, you can treat it recombinatorially. That’s probably never happened to an engineer. So naturally developers are inclined to seek stability, where their work will be useful, and may be uncomfortable where change seems likely, until they get comfortable with the idea that change is cheap. This is installing a new set of sensibilities, a substantial philosophical shift.
• #35: Beer! No, probably not. It’s just being ok being uncomfortable and being there anyway, because it will pay off. Like a first date.
• #40: We (should) do research at every phase in this process. And if you go to your design team tomorrow and say hey I want to be in the room for the next research They should say “great”
• #43: Don’t worry, they’re gonna show you how to be there. Like we do with everyone.
• #47: In any event, try to a avoid a straight “no”. If this is deep collaboration, it’s a question of understanding the goal and then working together to find a way there. It’s a two way street, to use a pithy piece of lame stock photography.
• #52: So just to recap… Be there early (even if it is tactically challenging or uncomfortable) Be there with users Provide the right, helpful input. And stay there.
• #53: Or, this helpful acronym:
• #54: eurS. You’re welcome.
• #55: Now go slack your designer about beer. :-)