This document serves as a foundation for the principles and practices that define Creative Technology at Automattic Design.
- You are passionate about applying new technologies -- making things not just for the sake of it, but to make a dent in our future.
- You learn new tools and stay up-to-date with technologies and frameworks in order to push our designs and thinking.
- You look at product AND process, identifying opportunities to make our design operations more efficient using technology.
- You lean into the possibilities, instead of only defining what isn’t feasible.
- You build and test ideas quickly to get a sense for the potential impact of an idea.
- You understand the value of a functional prototype
- You share work early and often, and are okay with not having the perfect answer all the time.
- You gather inspiration from a variety of sources -- not just design and technology but also art and culture.
- You prioritize shipping great design, and you understand that If it doesn’t work, it’s not real
- You keep the scope in mind, understanding and contextualizing requirements and constraints for designers and engineers.
- You are pragmatic and tool agnostic, never locked into one way of doing things.
- You try to understand the technical complexities of a problem before and during the design process, to ensure technical opportunities and limitations are fully realised.
- You design in code, and your code is well-designed.
- You notice how one area of product development affords opportunities for other areas and connect the two
- You understand that simplicity is key to good design and development. Your knowledge of both practices enables you to find the simplest solution to complex problems.
- Hand-hold, don’t hand-off.
- As you create a design, you don’t hand it off when it's done and move on. This is when the design has to meet with reality, and that process is messy, frustrating, full of compromises, and a crucial step of the process. As a creative technologist, you are along for the entire ride, and help make the vision come to fruition as best it can.
The Challenge: Old habits and tricks die hard. Pushing yourself outside of the same tools and solutions requires effort and bringing a critical mindset. At the same time, understanding which rabbit hole to dive down is crucial when trying to keep a high velocity.
The Solution: Take the time to research, explore, and map out your options for solving the problem. Investing this bit upfront can both save you headaches down the line and help generate buy-in from your teammates and stakeholders.
The Challenge: in the face of technical debt and changing requirements, estimating how difficult a problem is and how long it will take to solve.
The Solution: You can employ a few different strategies to rapidly bring clarity from the Creative Technologist’s perspective:
- Prototyping and quick technical explorations can significantly reduce uncertainty in situations where the scope is unknown.
- Mapping out technical dependencies between engineering and design – identifying where collaboration and communication is needed – can help teams prioritize work streams.
The Challenge: It can be tempting to take an idea and run with it, especially when writing good code can take long amounts of uninterrupted, focused time, amplified by a remote work environment. The risk of investing too much time without seeking feedback and context is high.
The Solution: Make sure you understand the whole user journey that the project your working on exists in. Give yourself stopping points that you come up for air and show your work to teammates. Share your screen often, and use tools like Figma and CodePen to show your experiments and work in progress.
The Challenge: We know that getting feedback is important, but it’s easy to get the wrong type of feedback. Knowing when and what to ask for is crucial.
The Solution: Below is a good framework for the conversations that are most appropriate to various phases of the design process:
- Divergence: “What’s the best solution?” Keep the conversation high-level, and prototypes that are gestural rather than prescriptive.
- Exploration: “How might we execute the solution?” At this point, you’ve decided on the overall direction, but there’s still room to explore how exactly to execute it. This is a good time to look at a few different code patterns or technical strategies for execution and weigh their benefits.
- Convergence: “How can we tighten this up?” In the final stages of the design process, the focus is on the details. Is the code performant and well designed? Have we tested that our solution is robust? Engaging our partners in engineering may also be an important piece of feedback at this stage.
The Challenge: Considering how people actually use your work can be an intimidating proposition in the face of tight timelines and untested code. The Solution: Sharing something you've made with real users can be uncomfortable. Remember that no solution is perfect on the first go-around. Iteration is key. Ensuring that your work has well-defined and well-qualified success metrics is key to learning and iteration.
The Challenge: Not every potential solution has data to back it up immediately. Knowing when you’re onto a good solution in the absence of data is an art.
The Solution: Use your existing knowledge to make a hypothesis, and use data to validate your assumptions. Get creative about the ways you could create or collect the data needed to validate your assumptions. And remember, the sweet spot can be found when you trust your instincts and use data gathered over a reasonable amount of time to measure success.
The Challenge: Some might say that premature optimization is the root of all evil, i.e. we have a tendency to want to make our code perfect rather than express the concept quickly.
The Solution: Use whatever means -- code or otherwise -- you have at your disposal to express the concept. Figure out if your hypotheses are generally correct first, and then circle back to add the polish.
The problem: Every designer and engineer makes decisions that impact the product and users. Those decisions often happen separated from one another. That means disconnection and small, but meaningful compromises in the product too late to be fixed.
Why It Happens: Many designers and engineers may not be able to cross the bridge between both worlds. Or maybe they can, but they feel like they only belong in one vs. the other.
The Solution: Build the skills for both sides. Don’t worry about labels. Sketch as much as prototype. Talk to designers and engineers. Be a bridge.
The Problem: Our products represent years of good and bad decisions. They have technical debt. They’re built with technologies, old and new. This can prove overwhelming when trying to plant new seeds to grow ideas.
Why It Happens: All those past decisions and technical debt creates a lot of weight, like dirt atop a seed. That doesn’t leave a lot of room for new directions.
The Solution: Always dig toward the light. Bring not just ideas, but plans to put those ideas into action. Via sketches, prototypes and experimentation, always go toward what’s possible instead of what surrounds you.
The Problem: Talking about code that needs writing only goes so far. Real sketches or prototypes mean users are one step closer to interacting with something real.
Why It Happens: Designers and engineers care about their craft. It’s easy to discuss the ideal solution rather than make a solution.
The Solution: Committing code (rather than talking about what code to write) is a great way to progress out of a mire. Often times it's faster to build and test two proposed but conflicting directions than it is to discuss which one is right. Doing this also makes you aware of the technical realities you must work within for success.