Building the architecture behind the design

After spending three and a half years at Shopify, I went back to freelancing. But I missed product development. I like iterating on something continually, figuring out what works and doesn’t work for customers, and building a solid product to solve those problems.

I also missed the community aspect of working with group of people day in and day out for months and years. Of course, there are a lot of things that attracted me to Abstract. But most importantly, it was the people and their vision for moving the design phase closer to development that motivated me to join the team.

The transition from solo work to teamwork

I’ve been doing web development for almost 20 years. I started off doing agency work focused heavily on government websites before going into self-employment for about 5 years. During that time, I really honed in on writing for my own blog, online magazines, and speaking at conferences. Then, I got a job at Yahoo! where I quickly went from being the only person on a project, picking the technology and how I built it, to collaborating with a team of 200 engineers and 30 designers.

I learned a lot about how to make things work in an environment like that. I put that new-found knowledge into a self-published book on how we can structure code in a way that’s conducive to collaborating with multiple teams and products. The book is called Scalable and Modular Architecture for CSS  — SMACSS (pronounced “smacks.”) You gotta have a catchy name. It’s good marketing 😉

I wanted to share how we could apply patterns to bridge the gap between design and development.

Design in a multi-stack world

One of the problems designers (and developers) face is that design and development are being implemented in different technology stacks. As a result, design tools need to satisfy being able to design for a variety of both native platforms and web platforms. It’s hard to move from design to multiple development environments, and understand the constraints of all those environments.

A lot of design tools don’t help answer technical questions that come up during development. With most design tools, you need to create multiple artboards to handle every possible scenario for the plethora of devices and resolutions out there. What does it look like on iOS? What does it look like on Android? What does it look like on various screen sizes?

In the past, designers would design something, throw the files to development, at which point we’d discover edge cases and other weird issues. The feedback loop was endless. Launching something took forever.

But I think we’re turning a corner.

On the development side, we’re using tools like React and Electron. And we’re now starting to see design tools being built using web technologies. As a result, there’s a potential for designers to not only design, but to also prototype their designs because they’re using the material of the web. This means moving into production a lot faster than they previously could.

Today, design tools are definitely becoming more closely aligned with development. But there’s still a long way to go. For example, if a designer designs something in English, what does that look like in Russian? Greek? Arabic? We’re only now just seeing the tools that can help facilitate this.

Open design means something different for remote teams

One of the things I observed both at Shopify and at Yahoo! is the concept of “posting all your work on the wall.” Anyone can ask questions about the designs. And of course, designers had standups and design reviews.

But the online tooling was never there to support this physically open environment. The tooling was always akin to something like this: “I’m working on this on my desktop. Let me save it, export it, and share it. And, by the way, where’s the latest version?” If you weren’t in the office, it was easy to miss out.

Abstract creates an environment to facilitate these conversations online. Effectively, Abstract enables distributed teamwork for design like development has had for years. GitHub enabled and empowered distributed teams. It could be anywhere. And so could you.

It’s early, but I feel like we are one of the few companies focusing on remote work, and doing it well — not only on a product level but on a company level, too.

Building the future

As a developer, I see how Abstract comes close to a lot of pattern libraries. As we introduce more file types and integrate with more design tools, we’ll enable faster prototyping.

I believe that Abstract will allow us to not only design faster, but more efficiently move from design to development to production. Ultimately, we’ll see better and better products launched into the world. And I’m looking forward to building the architecture that enables teams to dream up things we haven’t even thought of yet.

Abstract is growing fast with a wonderful, passionate, diverse team. If this sounds like an exciting challenge to you, we're hiring!