UX vs. DX

I was introduced to Estelle Weyl through my colleague Ali, who suggested Estelle as a speaker for Mozilla’s speaker series. I was intrigued with Estelle’s teaching on the differences between how we as humans perceive the speed and performance of our web browsers (vs. the precise, technical “reality”).

She was of course great, and her final slide also called out another important distinction:

So how fun was it when, a bit over a year later, she invited me to moderate a panel on, yep:

https://forwardjs.com/schedule

We had Tomomi Imura of Slack on board, and were super fortunate to recruit Sarah Federman (newly) of Atlassian and Jina Anne.

This group was so amazing, they agreed to meet on a holiday before the event to huddle. It was there that the subtitle emerged:

We realize we hadn’t intended it, and while we didn’t want to make the Lakoff mistake, we did think it was cool.

So, whiskey it was.

Oh also, the conversation was as great as these women. Estelle and Timomi had previously posted different ways to tackle this. Estelle defines DX as “the methodologies, processes, and tools (frameworks, libraries, node modules, pre- and post-processors, build tools, other third-party scripts, and APIs) by which developers develop web applications for their user base.”

And, because developers are often users too (think developer tools, and of course, frameworks), Timomi approaches their DX in a way that exhorts developer tool makers to keep the developer experience – as users – in mind.

So as a group, we broke this down further, looking at why some developers may be tempted to not think about the UX (whether those users are developers or not, per above), and instead adopt a “resume-driven development” approach (h/t Estelle again) that favors them showing off knowledge of sexy new frameworks vs. delivering a solid UX.

There are also work culture pressures to deprioritize UX. Ship fast or first or cheap, user-be-whatevered, can be a hard force to combat when it comes from management.

But, as others pointed out, developers can still make the choice to not be overly-reliant on tools or frameworks so they can choose the best route for the end-users. Individual engineers can ask forgiveness vs. permission in adopting a user-centric, front-loaded design approach from the start. Finally, to steal (again) from Estelle:

Taking the time to do it right the first time is “fast to code”. Refactoring is not. If you keep the six areas of concern — user experience, performance, accessibility, internationalization, privacy, and security — at top of mind while developing, your finished product will be usable, fast, accessible, internationalizable, private, and secure, without much effort.

Estelle Weyl

CATS

I love ForwardJS and the opportunity it gives me to explore something different and significant. This year I teamed up with my Mozilla colleague Chris Riley, interviewing him on the future of Internet policy (which he heads up for us).

An overview is here, Chris’ full recap here, and the the video here — but here’s the spoiler: Competition, Algorithms, Tracking and Security.

Of course this is not meant to diss the Zig.p.s. some of my other ForwardJS talks: Creating a Strong Geek Culture, Being Effective in a Virtual World, and Building Trust Before Code: Unpacking the Weekly Retrospective. 

Retrospection on the Retrospective

A seemingly universal axiom for processes is that there is no universal process. They can vary as much as the people who practice them. Which is great when you remember that process exists to help people improve, and not the other way around.

So when the ForwardJS crew yet again invited this non-developer to speak at their bi-annual Javascript event, I thought of my trusted, respected colleague, DMose. One of the founders of the Mozilla Project, Dan has taken thoughtful and intentional steps to continually improve how he and his engineering teams work.

During my 4.5 years at Mozilla, I’ve grown to greatly appreciate Dan’s careful consideration of the process and human elements to his technical work. As we touched on some of these elements, we identified the Retrospective as a practice that can deliver many of these principles for teams.

Which, as with most processes (see above), has been tweaked, adapted, forked to meet the needs of the individuals using it. For Dan and his team, the Retrospective contains 4 questions, reviewed by the team at the end of each week:

    What did we do well?
    What did we learn?
    What could we have done better?
    What puzzles us?

The takeaways….

One Big Benefit
The Retrospective questions – in the above order – have done something critical for Dan’s team: they’ve built trust. More than any learning or process change, the development of trust among the team is what makes it effective. It allows for failure and its valuable counterpart, risk; and ensures that the costs of such risks are translated into valuable learnings for the future.

Another important guiding principle to create this trust is to not “shoot the messenger”: if someone shares something they think didn’t go well, it’s important that the team hears that person out and distances them from their feedback on the team’s performance.

Small things matter
Does the question order matter? Indeed. Because the questions start with a focus on things done well, the process begins with confidence. And by framing them in the collective “we”, and positioning failures as learnings or things to solve, the questions depersonalize negative impacts, instead reframing them as opportunities to get better.

From trust to change
Our session was quite lively (we took this to be a good thing), and one of our audience members cited the Retrospective as a key way they introduce changes to their org. Because the scope of the restrospective is often small (importantly, the work featured is positioned as “small experiments”, which allows folks to be healthily detached from the outcome), they allow for changes to be adopted while minimizing the fear and uncertainty that typically accompany change.

It’s this ability to introduce change in small increments that makes the Retrospective so empowering. Any team can adopt it.

We’re curious to hear of your own experience with retrospectives.