When to Design - and when to *design*
I've been designing Sonr for about 16 months in total. We've built prototypes, raised capital, tested, prototyped, tested - and then began to build out the core product - which is now in private beta. In all this time I never actually designed any icons. I used UI Kit for iOS. I used a variety of resources like Noun Project and Iconmonster. I originally used whatever came with Bootstrap. It's not because these design elements aren't important - they are. But they are not important until the workflow, framework and UX is designed and tested. When we initially moved past whiteboards and paper at the beginning of the Sonr project and we need to build a solid prototype, I sat in a room in Potrero Hill 8 weeks before the first investment round presentation and delivered a paper prototype with boxes and attributed actions. I didn't care so much what it looked like, but I did care about what it did. We chose a low latency framework - Bootstrap - and using it's modules and components which looked like ***generic website template no.4*** began to flesh out the boxes and actions. This was a time to design rather than design.
That was enough to do a few things - it allowed us to raise capital, test back-end architectures - and allowed us to realise quite a few things we got wrong with the product. Much is talked about technical debt - but design debt is also a silent killer in new products. Building a fully fledged front end too early inevitably means having to squeeze in features and newly validated workflows into an increasingly creaking - and expensive - architecture. Bootstrap got us around that. Much as it hurts to admit as a designer - no one cares about your icon set. Or your colour selection. Or your font. None of that is even noticeable if your product is weak or badly considered.
Spin forward 16 months and 50k airmiles later - and I've designed a v1.0 icon set (see above).
I have a hard coded set of colours. I have a GUI font in testing. Bootstrap has been replaced with a more scaleable and enterprise framework in react.js.
The icon set is a little complex as we run it as a font, allowing multi-state rollover / fill options to reside with the development team. This was a conscious decision as it prevents design slowing down product design and development. Design can be easily changed on the fly and through pair coding - not constant revisits to Sketch or Photoshop. Breakpoints can now influence icon behaviour. The downside is that we can't make cool interactive SVGs and GIF icons - but for a product in beta...it's just too much design for what users need right now. I mean I'd love to make 'em, but I know deep down it would be a waste of time.
In truth, the design in the product has moved on with the implementation of react.js - we now have flexible components, but these components have been simply assigned colour HEX and behaviours - they haven't been designed. This is sometimes a tough thing to communicate to stakeholders. Yes it looks sexy, but it's effectively still a lightweight wireframe - a really really nice one obviously - but it's still the product at its most basic. The design priority right now is load times, rendering issues, improving UX and architecture, testing, bug tracking, iterating quickly...not adding more design layers and slowing things down on the development side of things.
When we set out on the road of designing a complex SaaS product, we wanted the design to scale with the engineering. I didn't necessarily want to design a flat UI. I didn't adopt an existing design framework. We just ended up here through research, iteration and product / engineering requirements. It will of course be designed one day in the near future, once the beta stage is cleared and the feedback compiled. The design layer is of course required. But when that will happen I'm not so sure - it's probably going to be up to the user.