Being ‘Design Led’ and Prototypes

At Calorie Cloud, we’re moving a mile a minute. As a proper agile startup, we’re always looking for ways to work more efficiently. In a low-key experiment I’ve been running to test out being ‘design-led’, I’m already seeing the benefits of such an approach—even if it is under the radar. It’s easy for UX to become the bottleneck in a team that must be free to move quickly, so I started looking at where the most time was being spent, and how to create excellent output while reducing time needed.

The Argument for being Design Led

The reason I started this experiment is because, for the UNICEF Kid Power projects, our remote team is by-necessity collaborating on a daily basis with the US Fund for UNICEF (USF). Calorie Cloud is a wholly-remote and agile team working across 7 time zones, but USF isn’t. We’ve been diligently working together to find better ways of working together. One of the needs I identified was to reduce the amount of time necessary to get everyone on the same page when understanding a new concept, feature or CX improvement, in less time.

Enter being design led. Being design led means that design leads. It leads almost everything. New feature? Start with design. Interaction questions? Answer with design. Need to get the team aligned more quickly? Design first (because design is a universal language – people comprehend visuals more easily than almost any other medium.) We needed this productivity boost.

Starting with Prototypes

Prototyping is arguably the clearest way to communicate a new software feature to people who aren’t designers or developers. Simply put, clarity up-front saves time.; But we all know that prototypes can be a time-suck. This concerned me, so I looked at our history as a team of what steps were taken to reach a point where everyone understood a feature. I was shocked.

Previously we had discussed features on a weekly Google Hangout (without visuals), or disseminated them using our feature planning tool (in text and static attachments). It turns out, these lo-fi methods are a great way for key understanding to fall through the cracks, and then come bite you in the ass later. For our remote team setup, it wasn’t efficient, and was a perfect recipe for accumulating UX, IX and technical debt; because we needed to move forward quickly, it became nigh impossible to stop and clean up a mess we’d created in the process.

The Time Investment Paradox

When I looked at the time it took our team to get on the same page, it became clear very quickly that leading with a prototype (design) was the best first point-of-contact. Depending on the fidelity of the prototype, there’s potentially zero margin for error when needing others to fully comprehend the feature. Since I’m currently doing double-duty as UX and UI Designer (remnants of a past life), I have the opportunity to quickly create fully-rendered prototypes which are on-brand, on-message and—at the end of the day—usable by designers and developers as ‘spec’.

This unusual recipe afforded me an unusual opportunity; I could quickly Sketch layouts & flows using Paper on my iPad Pro, prove the concept within 5 minutes, then jump straight into Sketch & InVision to create fully-rendered design and prototype that would not only be pixel-perfect and accurate for internal presentation, but then be delivered straight to developers upon consensus. Compared to the previous set of communication, this would shift conversations to a point in the process where we all started with a uniform understanding and then jump straight into build – bypassing the back-and-forth lo-fi conversation time-suck.

Of course, prototypes are a significant up-front time investment, regardless of their fidelity. So what happens when we need to start planning, but a prototype doesn’t yet exist? This is the problem I’m hitting now; until UX/UI can be consistently ahead of the Sprint curve with these prototypes, the model isn’t always perfect. Just yesterday I found myself being asked when a prototype would be ready (granted, it’s two entire applications), and I had to reply “one or two weeks”.

But even with that kind of misalignment, there’s a part of me that still believes it’s worth creating a prototype up-front. I don’t have time charts to back this up, but it feels accurate because there are so many other variables than up-front planning involved; the frustration of misunderstanding is avoided, the back-end need for design & ‘spec’ to developers, and bypassing the risks of amassing debts. Surely when combined, these things speak for themselves about their true cumulative value.

Workflow & Tools are Key

We’re not all in this boat. I happen to have a strong background in UI design, branding & copywriting which gives me the ability to create and end-to-end, fully-rendered prototype in very little time. That’s unusual. On top of that, I have the tools I need; an iPad Pro & Apple Pencil for rapid concepting, a MacBook Pro, and a Sketch and InVision license and most importantly, the time to use it all.

Without these tools, this experiment would never have been possible. But in a way, we all have our base of knowledge that we can combine to leapfrog as many steps as possible to combine them into one whole way of being design led, aligning our colleagues and getting shit done.