PROCESS
Over the years, I’ve seen a huge need arise for the operationalization of design. It’s always good to have a full-stack team, but developers aren’t designers, nor researchers, and shouldn’t be forced to enter territory that is a dedicated discipline in its own right. Enter DesignOps.
As application interfaces grew more sophisticated with the use of user research and further tie-ins with slick, world-class brand identity standards, user-centered design inevitably became part of the product development process.
Now, more than simply addressing design as an afterthought as we did in the past, working UX design and research into the agile methodology has become imperative to the building of a holistic development workflow. With that in mind, I present myself often as more than just a product designer, but a “DesignOps” practitioner and evangelist. Here’s a little more about my process:
DesignOps Defined
DesignOps entails managing people, processes and the craft of design. Loaded statement, to be sure. Let’s start with people.
People
A small (always small), effective product design team will have one or more designers. They’re most likely wearing a research hat as well, and some even go as far as having development chops. Depending on where their strengths lie, you may see gaps to fill. See this image of what a small, two-person team might look like.
I’ve seen some absolutely horrid team organization in my time; from the expectation of one-person unicorns handling everything and burning out in the process, to overstaffed 10+ member groups with staff idling and on standby. This is an audit I often do when starting with a group seeking to build their UX division the right way.
Often, a holistic team structure is going to be the difference between success or failure, so I make it a point to sit down with stakeholders as well as team members to assess their needs, strengths and weaknesses, deficiencies etc. This is not a proscriptive process! After getting solid input, I’m able to fashion a grid such as the above to determine a personnel path to success.
Processes
I believe good habits trump process. There’s certainly value in certain recurring practices and checks-and-balances, but we need to keep things simple and easy to adhere to. I have a general, three-stage flow that I implement in line with that rule.
Working UX into the agile process is certainly an art. We don’t want to burden our release schedule, but we certainly don’t wish to be an afterthought. A consistent, contemporary experience has proven time and again to inspire trust and user delight. It’s part of our continuous improvement process as well implemented with new features.
As regards continuous improvement. I maintain a UX refinements icebox, that is shared with the team to contribute to as they wish. Every sprint we take a few items from this icebox, groom them, and bring some of them into our sprint plan.
I use Trello to maintain this kanban-style board. Trello is free has great reach and is accessible on several platforms. This is important when making quick note of items discovered through daily interactions with the product.
Above is a continuum of tools and processes to bring an agile, DesignOps flow to life in three phases, along with the tools/products of each phase. Note that each phase may take several sprints to accomplish and iterate with each new feature.
Phase 1: Conceptualize/Socialize
We use tools like Figma and Miro often in the conceptual phase. These are tools used to spark conversation among stakeholders, product managers and other leadership-level team members who are responsible for the vision and direction of the product. This is a free-flowing, conceptual phase; artifacts are easily shared and prone to frequent updates. These conversations take into account various factors such as competitive analysis, customer feedback, research results and the generalized user experience we’re all aiming to produce. We may do some interaction design prototyping at this phase to get a stronger sense of what exactly the experience will feel like on various device types, test concepts and report back to leadership with informed, data-drive designs.
Phase 2: Finalize
As we move down the continuum we solidify those conversations into a tactical UI design vetted by design leads and development leads alike. We assess things like feasibility, time/effort during our backlog grooming sessions, and other exercises such as empathy maps, user journeys and flows as shared with our development team so they also have a holistic sense of what they’re working on. The ideal is to have very few changes at this phase and if we do, to make sure to comment these changes in developer-centric design tools that allows us to look back and see what the modification was in case developers have to pivot within their workflow. We found Figma’s Developer Mode and Zeplin to be the best tools for this job.
Phase 3: Implement
Once development has staged the designs and marked our PBI (Product Backlog Item) to done, I’ll often come back with a “UX Review” task to make sure everything is on-point with what goes live to our production server. This is part of the QA process, but unlike code QA, this is circling back using the original designer’s eye. I’m looking for some of the more granular items that may not have been hit at first pass. Though our developers are very sharp, and tools like Figma’s DSM features help impart the design vision better than ever, this is my chance to make sure we hit the high bar set for our designs to be intuitive, as well as confidence inspiring though a uniform and consistent experience. Often, the result of a finalized implementation is awesome, reusable UI code. When this happens, we put the prototype component in our Figma DSM and the code in our Zeroheight or Storybook code library so other team members can use it as necessitated.
Craft
Perhaps the most overlooked but nevertheless important aspect of product design is the craft. The approach towards craft can be a differentiator between an average product and a truly inspired one. UX visual designers, researchers, and UI developers all have their own unique style and approach to product, and when you get into world-class product design, it becomes obviously that very little comes out of a box, ready-to-go. My approach to addressing craft, then, has been to try and harmonize of the unique strengths and talents of each team member to build something with consistency, that speaks to customers needs and wants, that sets the bar for user experience, and is rock-solid on the back end.
There’s an element of pride, an element of passion, that drives this aspect of DesignOps, and your personnel choices will be critical to forming the chemistry needed for this component. In my experience, heavily proscriptive management approaches never work, and there’s nothing worse than middle men and multiple levels of hierarchy to stifle inspired, creative work. Hire smart people, and let them do what they do best. As a designOps practitioner, you are a facilitator.