DevOps for Designers
Jeff Sussna

I guess I am not seeing enough of a call to action, or even examples.

I could rant for a long time about how my target-state- and ecosystem design (vs. designing only for this sprint or release) consider the lifecycle for years, across many platforms, and for all users (e.g. content, maintenance, as well as consumers).

Those orgs that take this to heart use these (even so far as to put the whole process map / task flow on the wall) and refer to the principles and plans when operationalizing the product. UX is involved in decisionmaking—or explaining previous decisions if not well enough documented—for OS upgrades, DB/API changes, bugs, and so forth. It also means that we can help decide when operational updates are going too far and need to be strategic decisions and get the design (software design, db design, etc, not just UI design) more deeply considered, and more robustly approved and integrated with other organizational activities.

But I’ve yet to see a truly operational-level, ongoing-engagement UX team or process that is quite where it could go; nothing like a DesignOps group, but it is still morelike the old days where the SysAdmin called the original dev to ask a question about something, and hopes he still works there to answer the question.

What other thoughts do you have, or if you’ve started engaging like this, what have you seen so far? What do you expect DesignOps to do every day*. What do you want to change?

*Me: I’ll nominate documentation creation/cleanup as a first big one. If I was to again make a large, broad, and in-the-org design team (we’re consultants now) one of my hires would be an archivist. Really.