We set out to connect design teams to dev guys. We launched SPECs

We picked from what you told us. 🙋🏻

A designer comes to CanvasFlip to create a prototype of this designs, share them to get feedback and conduct user testing on them.

Once there is enough discussion on the designs and it is all set to be implemented, the designer shares the same prototype with his developers to give an idea of what was to be coded. But was it enough for the developers?? Uhmmm lets see..

I was talking to a designer Ema about her time distribution with the projects she had. I am sure every designer reading this has already guessed what it would be like.. — she spend more than 60% of her time handing off the designs to the development team and revisions on the design 😳 . Just the next week I rolled out this survey to the designers in my vicinity.

Clearly, this survey result was an eye opener to the need of a hand-off tool for the designers.

We saw these results in the Monday meeting and immediately decided to push limits from just allowing designers to share and test prototypes. The designer’s workflow doesn’t stop there and so we couldn’t stop at that.

I still have a snap from our meeting then..

Deciding on what features are quintessential

There are a list of stuffs a designer passes on to his/her developer. How much ever we would love to plugin all of that in the design hand-off tool, he had to prioritise features for the first release. And how did we decide on that? ……Ummmm, well we asked you! 😉

The answers in the “Others” section were — Interactions, CSS code and all of the above. So we were pretty much on the right track. Based on these priorities, the SPECs we developed for version 1 has the following features —

These includes element positions, measurements, colours and font style used, export design assets with ease — all at once or individually, typography and style guides.

Solving the biggest pain point in hand-off

We now knew which button to press now — Comments/discussions on the design. The design of comments was crucial in creating the experience. It had to be present yet not interrupting all the time.

Comments weren’t just about the layout and hierarchy of static information, but rather, it represented a much more complex system in which large streams of discussion were funnelling from one end to another, triggered by various queries from the developer. A lot of conclusions had to be drawn from those and a lot of annotations had to be fed into the system.

We realised the need to move pretty quickly to prototyping various options for the comment section, in order to fully understand the way in which the designer and the collaborators could behave in a real scenario.

We tested on our assumptions of having “a sticky comment section” against “a comment mode which could be enabled or disabled”.

We had a clear winner in the situation, and we went ahead with a comment mode which could be enabled on or off.

The “final” SPECs

We are glad to develop SPECs, just the way you told us! 😃

After nearly months of work and weeks of testing and survey, we’re really excited to be launching SPECs and learning more about your experience with the tool. We’re hopeful that everyone in your team loves SPECs!

---

Developing SPECs based on your feedback! was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.