We are very thankful for the companies that have tried to tackle this in the past. LayerVault and Pixelapse are probably the two that stand out the most. In both cases, the products took a sync-based approach and lacked an understanding of what had actually changed from one version of a file to the next. As well, they didn't offer the concepts that most people would expect from a version control system such as commits, branches, merging, diffs, etc.

We started with the belief that in order to do proper version control for Designers, we needed to understand the entire file and be tightly integrated into the tools Designers use every day (we started with Sketch, working on more formats).

Like Josh said, it comes down to keeping things close together. We've got versioning and communicating design work, all directly connected to where the work happened. It's one package instead of syncing a bunch of PNG's to a handful of services.

/me goes off the record

That guy… he's pretty wonderful really. Likes coffee more than me, I think. Sure does love his family. And he's pretty good at this design thing. But don't tell him I said so.

Happy as a Brooklyn clam!

<3

/hugs

Thanks man. We really appreciate the vote of confidence!

This is my personal take on what success looks like: "Do you use Abstract?" becomes part of the design interview process.

"Do you structure and document your work in a way everyone in the team can quickly understand what you've been doing where and why?" "Do you know how to design in a team?"

For the team: We're extremely passionate about bringing more structure to the design process. Feedback from early testers has been very positive, so that definitely keeps us going :)

For both the team and the product, success looks a lot like designers everywhere finally having a platform that supports the entire lifecycle of the design process. Proper version control and a system-based approach to designing products becomes the new standard. Everyone in the company begins to understand the design process and can appreciate and contribute in meaningful ways. Decisions, normally stored in our heads, are now captured and available to others (how many times have you asked, "why did we do this?" and the person who did it no longer works at the company and no one else actually knows the reasons why...)

Oh and eliminating "conflicted copy" from our collective vocabulary :)

Josh did a talk a few years back where he addressed imposter syndrome by saying designers should be writing production code, which I thought was pretty unrealistic considering how specialized front-end has become (even Meagan Fisher eventually backtracked from a similar sentiment.)

So I'm very curious how he'd address your question today.

edit: Anecdotally, I have a programming background, both FE and BE, but the industry eventually pushed me solely towards UI/UX/whatever design (little to no programming expected or even desired.)

/me hugs Thomas Michael Semmler

Design (whether you call it "product design" or something else) is a combination of fashion, and the technological capabilities of that point in time. Both of those aspects are changing all the time, and the same goes for job titles I think. It's a way of saying "I'm relevant, you should hire me." Part of the job of being a designer (or developer), is staying up to date with what's current.

It's a weird profession to be in for sure, and I hope you can give it another try :)

Well, Daryl is here.

Should designers troll AMA's?

Seriously, you and you alone can answer that question… for you. :)

Daryl!

The private beta has been going very well! Many teams are starting with a few people testing it out and then inviting the rest of the team quickly. A lot of what we are hearing is around how Abstract helps you be more deliberate in your decisions, improves collaboration (esp around design systems, etc) and improves visibility across the board for what is going on.

And we are hearing that once you've gone through the basic workflow a few times, you've got it. And we've even heard people say, "I didn't think I would want to make commits but now I love it! Helps my team but it also helps me by leaving a breadcrumb of decisions for myself" And the first time you do a merge and it just works… pretty rad. ;)

As for timelines, we are inviting new teams each week. We thank you ahead of time for your patience and are working to increase the number week over week! Look for a public release some time in Q1 2017.

A couple quotes: “Optimizing for collaboration is critical to the design process at Mesosphere. We easily have 30 or more active projects in motion at any one time. Managing changes to our design files has always been mechanical, error prone, and inefficient. Abstract has changed all of that. For the first time we have a real version control solution built by designers for designers. They've really thought of everything.”—John

“Abstract helped me become more aware of my own design process, which has led to quicker and easier collaboration with others.”
—Jenn

“So just installed @goabstract to test version controlled Sketch files...Wow! really awesome piece of software, handles merges!”—Bryan

I don't know about fickle. I think Designers are an curious, adaptable bunch, constantly looking for new and improved ways to do the work. And to be fair, there are still tons of people happily using Adobe products to do their work every day. With XD, I think that there is yet another potentially great tool for proper UI/UX design. Similarly, Figma has a different take on what the world looks like and some people are really enjoying that experience. However, the switching costs to move a whole team from one drawing tool to another is substantial and most teams are probably already feeling some switching fatigue.

This is one big reason we chose to focus on solving the problem that all the tools continue to contribute to: binary files without version control and no good tool for file management and proper collaboration.

We are constantly thinking about what the world looks like in the near-term and a little further out, and we think that Abstract will be there supporting as many of these tools as we can!

We wrote our own git infrastructure. The Desktop app is built with Electron. Everyone on the team can contribute in some fashion, which makes it’s pretty awesome IMO. :)

The Abstract brand has been quite a journey. Frank took the lead and the two of us collaborated on the mark and the visual language. It’s interesting how versatile a mark needs to be today. Early on we determined that we wanted something playful but sturdy, built up from basic shapes, and if it worked, imply a sense of versioning/layering. Obviously, our starting point was the letter "A" but as you can imagine, there are so many marks already out there making a capital A out of geometric shapes.

The explorations were endless, some in new and different directions. Some were pretty fun/interesting, but ultimately not what we wanted. We began developing the idea of patterns and shapes in parallel and started playing with the lower-case "a" and that’s when it started coming together. We both talked about Paul Renner's alternate "a" from his early sketches for Futura and looked at even using it directly (it had a similar approach to what we we’re exploring), but it didn't feel right.

We use a stroked circle to represent a commit in the product, and the implied "up and to the right" arrow conveyed a sense of direction and refinement. Once we dialed in the proportions/spacing, we stepped back and everyone agreed we had nailed it.

1. Absolutely! The design process is a combination of people, team size, product type, market... Meaning that it's very different at every single company. Team members bring in tricks they learned at previous gigs, and the combination of all this is a process that will probably be different next month.
2. Abstract is made for everyone who's even remotely involved in the design process. Designers (obviously), design managers, project managers, engineers, VP's, CEO's... Whoever wants to take a look at the work that's been done by the design team, can do so with Abstract.

We (currently) support whatever kinds of organization Sketch offers, with some project structures on top. That's a lot of different levels you can use however you want to structure your work. Design will always be messy, and keeping things clean and structured (layer names, page structures etc) is a big part of the job.

Thanks Bobby, we're inviting more and more people to the beta every week, hope to see you soon!

The design process is a tricky thing, and, as we've learned from research, might be very different depending on which design team you're looking at. Our goal with Abstract has always been to imply certain workflows (not process), but keep things as open-ended as possible to cater towards however your team is structured.

Abstract currently doesn't keep track of research and sketching (unless you do that work inside Sketch files), but it's something that's on our radar for sure.

We've heard of a few teams putting photos of sketches, whiteboard, etc in a Sketch file as a way to capture, share, and version this work. Often it’s on it’s own page and used a reference as the design begins to take shape. We are also looking at ways we can include links/references to documentation, research, planning, etc.

I’m sure Josh and Tim can provide a better answer than mine, but the Abstract website says:

It’s a version controlled workflow, built on Git

https://abstractapp.com

We built Abstract on top of Git. We purposefully chose not to build a sync-based architecture (ala Dropbox, etc) because of the inherent issues (can't resolve conflicts, doesn't understand the files). And yes, you make a commit to record your work!

Workflow-wise, we made some simplifications:

• Auto-fetch
• Auto-push
• You're not allowed to work on Master (need to create a branch first)
• You're not allowed to work on someone else's branch (you can branch off their work and update from their branch at any point)

All this, combined with some secret sauce and a GUI makes it that you only need to do 2 things: Do the work, commit the work.

We are aiming for a public release sometime in Q1 2017.