Argent (Not the real name) was a Fintech company moving in the wrong direction of design maturity. We were an early-stage remote design team developing a complex product and with the recent departure of our design director we were severely lacking structure and process.
I was fixated on one problem: How do we make processes that actually help us? In theory we had wikis, systems, etc... only none of them were being used. The joke became that wikis are "where things go to die" because once created they were never used again.
I'd had enough and made it my mission to design processes that not only worked in theory, but in practice as well.
Fintech
Design Operations Maturity
~10 Designers
Global
Any complex design challenge contains a virtually infinite number of problems. To bring order to the chaos I use an order of operations to solve the right problems in the right order.
The most valuable lesson I learned at Argent was the design order of operations from its now former design director. The idea is to solve design problems in the right order, his original order being Useful > Usable > Novel > Beautiful. Albeit a brilliant idea, it wasn't being used by the team, so I started to wonder how I could change that.
After reworking some of the principles and adding some of my own, I settled on Valuable > Usable > Practical > Presentable > Testable. These operations became our foundation for future design principles, reviews, and new components processes.
'Testable' was a late addition as I felt something implying the iterative nature of design was missing. Adding an operation to validate and document our designs and the standards they created was essential to ensuring the framework could function within our design org.
Principles are the rules that help designers make decisions and ensure consistency across our designs.
It always bugged me, every design team I'd ever been on had design principles... only no one ever used them. They were just theoretical, so what was the point?
As I formulated Argent's design order of operations framework I realized each operation would get its own principles. My team had workshoped a list the previous day so I grouped them together under each operation to create our starting point.
But the problem remained, how do we actually use principles? The solution was to embed them within our other processes, specifically our design review process and new design components process.
Each design would be evaluated based on those principles and any feedback given by designers needed to fall under one of them. If our current principles weren't enough we'd updated the principles, making them an agile product designed to serve us, not a wiki where things go to die.
Products are a reflection of the systems that create them. Designers should design their process with as much care as they would anything else.
Argent struggled with accountability and follow through. With any young design team there's a lot to do, not just for day to day product work but for improving the design organization as a whole. However these 'mini-project's often got lost in the chaos as the urgent crowded out the important.
To streamline prioritization and accountability I designed a kanban board in ADO. Design team processes were rated as either 1. None 2. Frustration 3. Satisfaction 4. Delightful. Anything we wanted to focus on for increasing design team maturity would go here from decision making processes to hiring practices.
We created a backlog then chose which to focus on, who was accountable and which rating we were aiming for. From there on it was simple project management but with transparency and accountability.