New beginnings: Designing our first steps to get the CSIT digital product design team off the ground
When I tell friends I am a digital product designer at CSIT, the conversation typically starts off with “Oh, what is ‘CSIT’?”. The next question is usually “Why would you want to work as a designer in a defence-related government agency?”
Cue mystified look. (。_。)
2 years ago, people asked if the designers were here to help “draw the UI” and “pick their app colours.” 2 years in, a few colleagues still ask for the same favours and we’re definitely not yet at a Level 5 design maturity, but hey! There are now a lot more people who know drawing UI is not our main job, and even proactively reach out to ask “How can I get a designer on my team?”
Does small celebratory dance. ヾ(･ω･*)ﾉ
So… how did we get our design team off the ground? Here’s our story.
Start here: Research and understand the landscape
Starting up a design team isn’t revolutionary. The difficulty always lies in designing the first steps to get started, appropriate to the organisational context. For designers, our design research toolbox can be put to good use here, to first understand the landscape and eventual value the design team can bring.
In our case, our research was a combination of very informal stakeholder interviews, a lot of casual coffee chats with stakeholders, and sometimes asking to be allowed in as an observer to product ceremonies.
The findings were… not too surprising. Essentially, design understanding was very low. Design work was mostly ineffective, not reusable, inconsistent, and often not even recognised as design work. There was no formal process to support design efforts. Design tooling was inconsistent across teams.
Designers were far and few, and though they were incredibly passionate, most designers were junior or mid-level, still requiring a lot of guidance. Product managers (PM) and engineers were often actual doers of the design work, a somewhat unfair situation for them since this was not actually their core responsibility. Management and user support for design was uneven — a few were very supportive (which explains how I could even land a job here), most were ambivalent.
And yet, research also revealed that there were actually also many opportunities for design to become a valuable partner to product and engineering.
The biggest unfulfilled potential we immediately saw for design was in facilitating coherency — CSIT had many enterprise products across many distinct workflows. There was need to ensure that information architecture and experiences across products were harmonious and purposeful, so that users could work effectively and efficiently across all these products. The unintentional lack of dedicated design bandwidth had prevented design from stepping up to this challenge. Could we ever get design to a state of maturity where we could deliver this value of facilitating coherency? What would come after for design?
Starting state?→Better understood. (•̀ᴗ•́)و ̑̑
Desired end state?→Vague, but there’s something there. (•̀ᴗ•́)و ̑̑
Steps in between?→Oh-kay… (ಠ.ಠ)
Many roads to maturity: Identify where to play and your starting strategy
After understanding the landscape, figuring out how to move ahead can still be quite daunting. Where do we even begin?
For us, we started by breaking down what makes up a design function, and then tried to design appropriate and coordinated strategies for its constituent parts accordingly. Building on the Design Management Office concept by John Devanney, we defined our design function to be these 3 pillars:
- Practice of design on digital products
- Platform on which design is done.
- People practising / enabling design.
With this breakdown in mind, we could begin thinking about where exactly to play. Should we split our resources across all 3? Work on 2? Focus on 1?
The answer? It depends.
If our team had more resources, maybe pursuing more pillars would accelerate design maturity more. If our tiny design team was mostly experienced designers, focusing more on the Platform and Practice pillars might have been a good choice.
For our team, we decided on the following:
- Practice: Only focus on a few projects, and try to ensure design work there was done well, without trying to contribute to product strategy or coherence, yet.
- Platform: Only invest to the extent necessary for our designers to function.
- People: Support our designers in making good impact on the projects we were assigned to, using those opportunities to also level ourselves up so that we can make greater impact down the road, and to also begin nurturing the community around design.
It was not simple translating research to these choices. In short though, we essentially balanced resource constraints against the highest value we could generate towards design appreciation.
As a team, we didn’t have sufficient experienced designers to drive Platform investments, and anyway, Platform improvements usually start benefiting designers first. Doing too much for Platform could even be seen as designers’ navel-gazing, and hurt our standing before we even had one. For Practice, since most of our designers were junior or mid-level, we would be taking too much risk by working high-complexity but high-impact projects. We also couldn’t take on too much work since we were a very tiny team relative to the organisation’s size. Hence, why not each take on a single product and try to do that really well? I.e. less, but better?
Our resources could then be focused on People: inwards on making sure our designers could deliver within our assigned scope, whilst improving our design skills simultaneously to deliver more impact in the future; outwards to begin building strong relationships with the community, so that future Platform investments and higher value Practice work could be better supported.
Focus on the People pillar it seems to be. (＠_＠;)
More thinking required: Translating to actionables, without losing sight of the bigger picture
These strategic choices were translated to more concrete actionables, which for us, manifested mostly in our design team setup and rituals.
Design teams can be centralised, decentralised, or hybrid/matrix. Since we decided to focus only on making the existing work better as a start, and on building strong relationships with the community, we supported and agreed with conforming to existing reporting structures, instead of pushing for designers to report into the design team. In CSIT’s case, this meant decentralisation, with designers reporting to product managers, alongside engineers also reporting to product managers too.
This choice has obvious downsides — designers might not be able to easily seek help or learn from other designers easily across their reporting lines, and we could prevent design from reaching its long term value of facilitating cross-product coherency.
To counter this risk, we negotiated for every designer to have 30% of their time, in the near term, ringfenced to seek and give support to other designers, and to learn from each other’s work. This 30% time was often spent on rituals such as regular bi-weeklys, design team exchanges, and even just time to meet and relax in a shared space.
For design’s longer term goal of facilitating coherency across products, a ringfenced 30% time would however likely be insufficient to counter the daily friction of product team boundaries and reporting structures. We therefore laid out strong recommendations that design should eventually be shifted to a hybrid/matrix structure in the long run instead of the current decentralised model, for design to overcome these hurdles and to better serve CSIT. It wasn’t clear when this structural shift might happen, but laying it out was also a reminder for ourselves — this is where designers shall strive to play in the long run.
Would all these preventive measures actually work? Only time could tell and only an agile mindset could help us pivot, if necessary. In any case, after all this planning, it was time to execute, to know how things will actually play out.
Time to get cracking. ┌(・。・)┘♪
Go forth, but brace yourself: The roads ahead are very bumpy, but the sights are worth it
And since then, it’s been almost 1.5 years of heads-down focus — our designers have been embedded into various product teams as planned, supporting their teams ship better work with good design, participating in design team rituals, and just working hard to demonstrate design’s value in our organisation.
Along the way, we learned many lessons and had to make a few course corrections. For example, despite the ringfenced 30% time, a few of our junior/mid-level designers still did not have sufficient support in their work, especially if they were in product teams more resistant to changing their ways. This happens in every organisation, but there was the need for the senior designers to step in to mediate or provide additional support, and the whole experience was definitely not pleasant. For me personally, this has been the most painful sacrifice of the journey thus far, and I often question if I had made the wrong choice advocating for the decentralised setup when we had so many juniors/mid-level designers. Perhaps we should have advocated harder for the designers to work in pairs as well? Perhaps we should have only the mid-level/senior designers embedded into product teams, whilst juniors supported their work?
Nevertheless, if we zoom out, our tiny digital product design team has still delivered a lot. On the whole, the team has accumulated many small successes and wins. We’ve built up some processes and resources to make our work slightly less manual and tedious, though more can be done. Our designers have slowly but visibly leveled up, product partners generally understand and trust us more, and stakeholders are starting to demand more from design. We also managed to get design formally recognised as an equal vocation to product management and engineering.
And there have also been many emotional ups too. The same engineers assuming designers were there to “draw the UI” are now also the same who tell us “wow that research session was super helpful for me” and “hey we should do more user research on this thing.” That’s progress.
So… this has been our story so far. There are many things we could have done a lot better, but I think we’ve also got some things right. And this story will continue, hopefully with a continued upward trajectory. Moving forward, we’ll start scaling a little bigger — still mainly focused on supporting our designers to ship good work where they are, but now with different tactics — the senior designers should step back from their product teams to support all other designers and their teams more, so that we build up more wins. We’ll also start facilitating some collaboration for designers working on related products/journeys.
As the journey continues: Seeking exchange of ideas and travel buddies
Coming back to “why would you want to work in in a defence-related government agency?” — the story thus far has been precisely why I joined CSIT. For me, it has been a tremendous growth opportunity to help establish and grow our design team. The “business” we’re in, as a government agency contributing to our nation’s security, adds on to the difficulty of the challenge, and yet also gives great meaning to all the work we do here.
Are you part of a design team yourself? We’d love to chat and hear your story too because there’s still plenty for us to learn. Otherwise, if you’re a designer who loves working on complex enterprise apps or even teaching others about design — we offer valuable front-row seats to observe how a young (but talented) design team could scale. Join us if this sounds up your alley? ←(>▽<)ﾉ
Post-article credit, featuring many heroes
This was not a journey designers could have embarked on alone. Here’s an incomplete list of thank yous and credits that we therefore think is essential to include:
- Members of CSIT senior management for being true sponsors and supporters, as well as our various design champions.
- Ee Kwang for his co-stewardship in this journey, and our team of extremely lovable designers.
- Our product team partners and peers for their understanding and willingness to experiment.
- The users of our digital products, for their patience and support as we strive to do better.
