Thinking about a system to maximize for creative output
I currently lead and manage a creative studio, a group of designers and developers, focused on incubating new concepts at NAVER.
A few months back, I was invited to speak in front of a creative community(primarily designers and then a mix of a few other disciplines) as one of three guest speakers on how system plays a role in creative work. I shared how I leveraged existing systems to push for ideas, what I was mindful of not to be constrained by, and about setting up the process at my current team. I was there to share what I’ve learned from my experiences, but I also took away new thoughts to ponder for myself about what a system means.
What is a system and its role?
System is defined to be an organized or established procedure. And a system and its procedures exist to fulfill a purpose more effectively. Funny thing is, it is not uncommon to see folks perceiving and treating systems as hurdles rather than help in getting their tasks done.
Oh you can’t just do it. You have to go through steps A-B-C then get it approved.
You need to change that design. It doesn’t follow the set of patterns defined in the basic guideline.
These are likely not why the system was implemented in the first place. Rather than to become constraints, systems were designed make things easier and to help guide the work to successful outputs.
System for creative work
So then, what kind of system do we need to achieve creative outputs more effectively? More specifically, I started pondering what system would be practical and add value to what my team & I work on right now. I’ve had opportunities to think about this more so than before throughout the past 12 months, because I was starting out a new team from scratch and was building a new process along with it (& we are still evolving it).
The core creative work in our studio focuses around the following:
1. Discover new problems
2. Imagine new experiences to turn these problems into opportunities
3. Design (the experience & the visuals) and Develop (working proof-of-concept that can validate the possibilities through day-to-day usage with real data) rapidly to test & iterate on what we imagined
Translating these into a bit less ambiguous goals (not in the same order as above), a helpful system would
A. Make it easier to get into the rhythm of exploring & detailing out the problem space when starting out with a high level problem topic (or sometimes a hunch)
B. Optimize the process & communication to enable a fast design ⇄ develop cycle
C. Ease the tasks distant from the core mission, so the team can spend time on what’s most challenging
A. Creating a rhythm of exploring & detailing out the problem space
Since we operate as an independent studio in the company, we are often in a position to self-initiate projects & propose them to the management rather than be given specific projects to solve. Most of our projects start out with a high level problem topic.
Since we start out a lot more open-ended compared to being given what to design or develop, some of the studio members have expressed uneasiness in the past. And this doesn’t come at a surprise. Many constraints are not fixed and with many elements open to interpretation, this is not the process that everyone is accustomed to. The process of defining what to solve for is a difficult job (I believe they are often more difficult than going out & designing solutions for the problems already defined), and that’s why it’s rarer to see ideas that add novel value to the world as opposed ideas that take an existing value proposition & re-designing for it.
But we do have a small process set up to tease out perspectives & approach this more systematically. Taking advantage of the team’s multi-disciplinary make-up, we run through a two-step process to collectively define the problem space and what is meaningful to solve for.
First Step: Look at a problem from varying perspectives to collectively define
- Every member goes through research to find what seems relevant or tangent to the problem topic.
- Everyone shares their findings, and each person jots down what resonated with them on a post-it.
- Group the post-its through affinity diagramming, but do it silently first so interpretations remain open & unskewed to any one point of view.
- As post-its find their place on the wall, go through each post-it & describe what each thought meant to capture.
- Label the groupings, and prioritize the top buckets to go after during the next step.
Next: Sketch together (designers & developers) to see what elements we should take into account and how they would interplay with each other
Goal of the sketches isn’t about what layouts we can come up with nor it is about finding the best visuals. We focus on articulating & sharing how each of us envision certain problems to be solved.
After going through these steps, we are able to make a better-informed decision on how to move forward. Often times, we move forward onto start shaping the experiences. However, there are seldom times when we drop the project & move onto a new problem, because this process allows us to determine quickly how valid the topic is for the studio to tackle. It is not a failure if the project stops here. Actually, it’s a successful learning we take away that we should focus on a different problem.
B. Optimizing the process & communication for a fast design ⇄ develop cycle
Unless a set process has been solidified & practiced within the team for some time, there’s a good chance that each person has a different expectation of what output they need to deliver & what they need to hand over to their partners.
The studio I lead have only existed for a year at the time of this writing (We started out on January 2017), with the team starting from scratch & slowly growing in size throughout the past 12 months. Some members are external hires, while others are internal hires who applied and were interviewed for the position. Considering that it’s almost been a constant period of transition & transformation, I feel good overall about how we came together as a team so far. Nonetheless, there have been gaps among the team members that resulted in a less-than-ideal design ⇄ develop cycle.
Specifically, there has been a series of discussions between around what a design handoff (or in other words, a spec) should entail. I’ve observed a few potential reasons why.
- No template or precedent to follow.
So everyone is drawing up a different output in their minds. We have been defining the process as we evolve.
- Not everyone has the same collaboration experiences.
What they’ve delivered in their handoffs, and what they’ve received in handoffs from others.
- People have different strengths, which means people have different weaknesses.
The expected output may require holistic thinking and architecting the experience end-to-end (ex. General product designer), but some are specialized in specific verticals (ex. Visual designer); vice-versa. Not everyone may be trained or apt in creating what’s required.
It goes without saying, but having a clear system of the expected deliverables (especially across different disciplines) seem incredibly important to have an effective communication to not have anything be lost in translation. Otherwise, it will result in an unproductive loop of time, resources, and responsibilities being wasted back & forth. This is nothing new, but we’ve had the chance to experience it & recognize its importance again since there was no existing process to build upon.
C. Allow as much time as possible to focus on what’s most challenging by easing trivial tasks & minimizing duplicate efforts
For our team, the most challenging work is around discovering new problems and incubating experiences at a fast-paced manner. Here are a few areas that I’ve felt are important to address for the work that lay ahead of us.
- Don’t waste time re-doing & re-creating.
We should focus on solving a new problem or building upon what we’ve already accomplished, rather than spending time re-creating what’s already been done. Openly share all design assets, upload completed research for all to see, and modularize code for reuse so everyone can put their focus on what hasn’t been done yet.
- Don’t fail on the same point twice.
Document how we failed so we don’t fail on the same point again. Failing is fine, as long as we learn from it & don’t make the same mistake again.
As our collective knowledge as a team builds up, an effective system would build up with it and become better at serving the needs of the team. We’ve been addressing parts of the needs above, and would be interesting to see how we can evolve the system to fit all of the needs.
System is just one part of the equation.
Work hours x No system = Baseline output
Work hours x Well-designed system = 1.x times the baseline output
Work hours x Well-designed system x Right people = Exponential output?
I think building a system is one part of the equation. And no matter how well a system is designed, it doesn’t hold its value or meaning if it doesn’t get used properly. One system does not fit all, and a system should be adaptive & optimized to each team and its mission. The other (just as important, if not much more) is bringing together the right people who believe in the team’s mission, can adapt / utilize the system to leverage their strength, and push towards the mission together. With the right people & a well-designed system, the same efforts that we put in can be augmented & multiplied into more creative outputs.