Working in a startup is a formative experience, especially for designers or engineers. Being in a smaller team, working all together on the same product, you can really focus on improving all the important aspects day by day, release after release, following the whole process of the implementation.
One of my first task was to review the app that was built between the first release on 2011 and the new release at the end of 2012. The app had a complete new design, but it kept many elements and screens of the previous releases, as well as many visual differences and inconsistencies generated during the coding implementation. We started organising the screens and defining a common visual language, creating rules and guidelines for each element of the app. The process took several weeks, and the guidelines were updated every time when necessary.
CONSIDERATION FOR DESIGN
The consistency document has been very important for the look and feel of the app, and for its UX (as overall positive aspect). It’s been really significant also to simplify the implementation process. Every time that engineers had to implement a new page or element the guidelines could help defining it with clear rules. A visual language is not — only — about the appearance itself, what is nice or less nice: it’s a matter of what works and what doesn’t work. This easier and rational communication between design and code brought also to a closer communication between designers and engineers. We could learn to work together with understanding more and more the mutual needs and limits; we could push the interface to something new for our standard, experimenting with interactions, and exploring alternative solutions. The visual consistency released and unlocked further possibilities, as well as a new kind of consideration and attention for design among the engineers.
CONSISTENCY OVER DIFFERENT RELEASES
The release codename “Fugu” was the first release with a new design after the consistency document, with the complete application of the guidelines. In the releases after Fugu the application of that consistent design could ease us from that part of work, and we could focus on new features and interactions.
WIREFRAME, PROTOTYPE, USER-TEST, IMPLEMENTATION
In Triposo we did prototype every time we needed to test a new UI, interaction, or feature. These prototypes followed initial sketches and wireframes, and were tested within real devices and real users before implementing the modifications in the app.
Checking the analytics about the usage of the product is a very good way to test your proposals against something concrete. Design modifications can be more effective, and support the real users base. A/B testing is another useful resource, we used this method for icons, navigations, and many other cases, with data analytics, and direct users testing.
DESIGNING FOR THE PLATFORM
Consistency means also to be consistent with the platform you develop your application to. Triposo focus on the iOS app as main release, but the same great features can be found on the Android version, and on the website as well. The consistency document took in consideration also this overall consistency across different platforms, respecting the inner guidelines of the platform too. While the branding and the visual language remain consistent across different platforms, the platform itself must be included in the design process. When the iOS7 beta was released it obviously had an important impact on the new version of the Triposo app (Fugu and following releases). I started considering the main aspects of the new environment and its aesthetic.
The same kinds of considerations took place for the other platforms such as Android, and Windows Phone (just a concept), and the Apple Watch later on (just a concept).
Originally published at www.claudiogomboli.com.