The SI Design Team
Who we are
At SI we work in independent subteams. Each subteam has at least one backend developer, one frontend developer, and one UI/UX designer. Teams have their own roadmaps and can drive their process as they like to.
It’s important that sub-teams don’t drift apart, so all designers meet frequently, exchanging information, discussing global style issues, and thus make up our Design Team.
Timur is all about the front-end! If it’s not pretty, it’s not good enough for him. Sometimes we’d love to insert unclosed HTML tags just to tease him, but he’s also working on our videos, features, and website redesign, and we can’t take the risk of him exploding.
Kolja lives and breathes front-end, and he formed the backbone of our “Responsive Riders” subteam that transitioned SI to mobile. He’s also passionate about front-end build processes and our LESS architecture.
Lucas has worked many years in Graphic Design, Marketing and Web development and is now Team Green’s UI/UX Designer-Developer. Daily tasks include writing CSS modules, ReactJS components, wireframing new features and developing new product ideas.
Charisse De Torres
Charisse comes from a graphic design background who has found her way to front-end development by building her own website from scratch. She primarily works on improving the UI.
Although Paulo studied design at the Faculty of Fine Arts in Porto, Portugal, his passion was always about making things useful first, and good looking second. His current focus is on user-centered design. Call it UI/UX, graphic design or web design, the target user is always the top priority.
How we work
Whiteboard and paper drawings
Each project begins with a rough written draft, and a kickoff meeting that involves PM, developers, designers and a customer-person person. Once user stories are broken down into manageable chunks, an MVP is solidified and the product design work starts.
We use whiteboards and paper drawings to try out ideas, discuss and iterate quickly.
Lots of future problems can be avoided by coming up with good quality wireframes. Here are two examples of how we first designed the overall architecture of the activity stream, then followed by an actual sample wireframe.
We don’t take wireframes too seriously of course. Wireframes are a plan, not a committment to the future product.
Also, quite often the real challenge lies in the user flow, not just in screen design. Some flows can be simulated at the whiteboard or by moving paper pieces around, but we typically move to InVision quickly. Using a webbased tool allows us to create actual clickable prototypes and get insight from remote staff easily.
A high fidelity image can raise unrealistic expectations (“oh look we’re almost done”) or draw attention to the wrong details (“why are there 20px margin, shouldn’t it be 30px?”). But on the other hand, the more realistic our mockups look like, the more and better feedback we get from outside the core team.
It’s not about pixel perfection at this stage, everything can still get moved around. But it is about making things feel “real” quickly, so that staff feel encouraged to give feedback about the flows, and so that early access customers feel they are actually commenting on something we are serious about.
Code level prototypes
We prefer to not write code before there has been some agreement on the flows between screens. Yes we’re agile, and yes we can make changes down the track. But starting to code user flows without first sketching them out has failed us too often.
So once we start coding the frontend, we have a somewhat good grasp of a feature, and this makes coding quicker and styling is also more fun when you know it’s most likely not thrown away the next week.
As designers we love to get down and dirty at the UI level too. But it’s not scaleable to be positioning every button ourselves. We invest time teaching design principles to frontend developers, and make everyone follows our living style guide. So that we can focus on the advanced stuff, not on placing basic buttons.
User testing and launch
Once a feature has been developed to alpha stage, it’s time for user testing. We aim for conducting some some 5 “successful” user tests for larger features or changes. If user tests show there are major problems in our ideas, then we reset the counter and keep adjusting the design and schedule further user tests.
Once when tests show that a feature works, it is time for the polishing phase, and our beta program during which we ship to a subset of customers. And then it’s time to roll out for real and celebrate! Here’s the launch blogpost for the Activity Stream for instance.
We love paper, we love whiteboards, we also love InVision and Photoshop especially when it comes to designing flows.
One of our major recent projects was the responsive overhaul. It was not just a massive CSS coding challenge, but since our goal was to make a very complex application work on iPhone 5 size, it was also a huge UX challenge.
Living Style Guide
One thing that grew organically during the Responsive Overhaul was the creation of a proper style guide. To make sure we actually revisit it all the time, it’s a living style guide, so all buttons and menus etc are based on the actual CSS.
Create Cycles UI Redesign
One of the core concepts inside Small Improvements is the “cycle”. A review cycle for instance defines who should get reviewed, in what time frame, what the questionnaire looks like, and what options to use or skip.
We’ve been working with an external illustrator to help us freshen up our internal badges, icons and sample users. While at it, we updated our color palette, and we’ve produced some cool feature tour illustrations (not live yet).