Can a prototyping tool change team roles?

Last time I talked about some of the limitations that prototyping tools have and a little bit of how the dynamics between designers and developers form the current prototyping landscape. We’ll explore this aspect some more, from an organizational perspective (taking into consideration my background in project management).

The Problem

Mobile App pipelines move towards a situation where designers are asked to be more programming-oriented. They are expected to design interactions that are solvable for developers. Nevertheless, there are parts of their design that might never see the light due to their inherent programming difficulty. There’s a gap in cross-functional teams that I believe could be solved by modifying the dependencies in the production pipeline. The key node lies in what designers are handing off to developers and how they negotiate design decisions.

Our solution

C4 Studio is thought of as a creative production tool that allows a designer the opportunity to animate their Sketch files. It would use a state-machine model where a designer creates “states A + B”, hooks those into C4 Studio and then is able to edit, tailor and refine the timing and motions between states. All in order to test animation ideas for her app designs.

Once they’re done, they would be able to export production ready (native) animation code. This is an outstanding idea, as far as animation tools go.

A major hypothesis behind C4 Studio is that putting a production tool that generates native code — that can also be used for prototyping — will not only benefit developers, but will actually give designers further reach into the development process and more positive influence over the final product.

By providing designers more reach and impact, C4 Studio will empower designers and alleviate the developers’ responsibility, thus modifying the nature of their collaboration. In other words, blurring the line between design and programming in today’s app development teams.

Exploring the concept

In exploring this concept, our team developed some cool ideas that can be considered during the making of C4 Studio:

1. A ‘prototyping tool’ should at least have simple visual language, prompts and intuitive iconography. In hindsight, this would reduce the learning curve and perceived ease of use. Thus, this tool appeals more to designers, a user type considered to have high spatial intelligence.

2. If we include some recognizable/expected tools in C4Studio, designers can create animations and interactions themselves more intuitively. We’re assuming that prototyping programs in general use a similar mental model that includes object properties, layer hierarchies, contextual menus, visual icons and more recently gesture tools and some form of transitions customization.

3. Software that exports code would make for a dreamlike situation for hand-off dynamics in teams of designers-developers. Particularly, it solves the following situations:

• Provides the developer with specific guidelines for the behaviours the designer is expecting to see in the app. Essentially, it’s a literal translation that reduces uncertainty in their communication.
• It reduces the amount of work for the developer.
• The designer sees his design decisions being fully implemented without loosing much detail.
• Enables the team to build higher fidelity prototypes with less effort or simply start building the final app right away.

4. C4Studio could help designers experiment with logic and design interactions that include conditionals. Imagine a visual language that allows designers to input logic such as this: “if swipe-left gesture is activated, then trigger animation 1; if press-hold is activated then change the state of selected object”.

Possible impacts!

As a manager, I see entirely beneficial outcomes for these ideas. It eases my work, by helping me coordinate communications and clarifying responsibilities between Designer-Developer teams. Such a tool would probably have behavioural effects in the interactions between these two players, mostly by modifying their expected inputs and outputs.

Arguably, this new paradigm would impact team efficiency by reducing programming sprints and negotiation between team members. As a manager, having more developers’ availability allows me to relocate these free resources in other company activities and projects. This maximizes my team’s performance and bolsters a leaner pipeline.

C4 Studio has the potential to empower designers. In exchange, this creates an opportunity for bettering a new app’s user flow, as most of the design decisions will reach the final product/prototype without much alteration during the programming phase. However, we would still have to study how designers and developers react to modifications in their pipeline, there’s always the possibility of encountering some resistance to changes in responsibility distribution.

Till next time,

David G.

Jan 2016