Swapnil Acharya
This article was previously published in the Leapfrog Technology Blog. If you wish to read the original post, view it here. Leapfrog is a technology-based solutions company. In the last five years, our expertise has grown from software engineering to product design, data analytics, and innovating in emerging technologies. While we’re totally excited about the growth, this has brought a problem, — a good-to-have problem.
How the design process at Leapfrog works, and how we’ve been helping our customers build better software with a thought-driven design process
The challenge of consistency
We have clients across multiple verticals, partnering with us on multiple projects, and using multiple tools and technologies. Consistency is now suddenly a challenge, and it is important that everyone speaks and understands the same language. I’m talking about the consistency in the language of design — why design is the single binding idea that connects each and every individual working at Leapfrog. This connection is crucial for the integrity of the company and our mission to achieve higher goals. We want to achieve three things with our design playbook. First, we internally communicate and execute the design process consistently well. Second, we educate our clients about the design process, and third, we design solutions that work for the end users. We thought through the design process. We tinkered and iterated over our design process. We took inspirations from processes such as design thinking and design sprints. Finally, we customize the design playbook to suit our unique situation that achieved all three things. We’ve tried to keep things simple and sane. What we believe in are pretty standard beliefs, and we hope it’s easy to understand and implement for clients, partners and new members joining the ever-growing Leapfrog family.
Why this design system?
Four years ago, we were an out and out software engineering company. We didn’t have the design competency, though we wanted to have one. We were high on data crunching and algorithm mixing — but we understood that we wouldn’t be able to build great software if our people did not understand what they were building. We needed a design competency. We worked on it and we built a kick-ass team. These are not UI’s and design assets I’m talking about here — I’m talking about answers to the “why’s.” Why are we building this? Why does it matter to us? Why will this make us better at what we do? All the stakeholders associated with a project: developers, clients, project managers, technical leads, designers — it’s important that everybody understands and accepts the product we’re building and owns the idea. That’s where our design system kicks in. We’re trying to convey an integrated and consistent message to our stakeholders on why we build, what we build, and how we build. What goes in our mind when we’re thinking about building something, or how we intend/plan to address change. Our consistent belief on how we should design the product for optimal performance and scalability comes from our understanding and acceptance of the design system. It is lifeblood that runs through our designers and developers, and what seeps into our clients and partners through the design process.
How do we do it?
By studying success stories of big and successful companies, we implement the best practices in our design process. We know that it’s not perfect and we’re not there yet, but this is an iterative process. We can quickly adapt our system to match the demands of specific projects or technology, or quickly try and implement something new to see how it goes for us. Most of the time times it works, sometimes it doesn’t — and that experience steers and accelerates our process forward. The evolution of the process is fascinating!
What we believe in
Here are the core values we believe in. These are things that we live by, and encourage our partners, customers, and stakeholders to do the same.
Design beautiful stuff
“Design must be useful, delightful, and beautiful”, said Don Norman. First impressions have lasting effects. We always strive to design visually captivating and inviting interfaces. A good UI works like an icebreaker to start a conversation. Consumers going “wow” is our ultimate motivation. The first thing they see when they interact with the product we build should instantly bring that sparkle to their eyes. Strive for quality. Make sure everything is thought through to the last detail. Use nice colors, use happy fonts, use subtle animations — some of the things live by every day.
Think about the user at all times
Most of the time we forget who we design for. Do we design for the customer? No. We design for customer’s users. We always keep in mind who’s going to use the product that we design. We make sure we understand the users and try walking in their shoes at all times. What would they do? Would they do this over that? Would they prefer this or would they like that? These are the questions we seek answers to. However, this process isn’t always simple. A lot of the times when we begin, we’re clueless who the users are, or receive misleading facts about who our customer thinks their users are. Sometimes, a polite “no, you’re not the user” works where the customer is biased towards defining their user.
Deliver on time
An awesome piece of design not delivered on time is not a good design. Customers come to us with time-bound requests. We take every measure to make sure we deliver on time — and that could even mean challenging what we’ve religiously believed all our lives. A good design should be able to fulfill its purpose at the right place at the right time.
Measure success; trust data
Sometimes we love what we do so much that we become biased. Sometimes, a designer is unable to let go of a feature that doesn’t work for the users. No matter how much we love a wonderfully beautiful web form that we’ve designed, if it is causing massive drop-offs among users, we’d let go. It might be painful but we know that’s the right thing to do. Our barometer for measuring success is how rewarding the experience has been for the customer’s users, and how profitable to the customer.
Leapfrog Design Process
We start with a blank slate and complete the beautiful picture at the end of the process. Then we take a step back and look at the bigger picture to see how we can make it even better. Though the process slightly differs from project-to-project based on budget, time and nature of delivery, the guiding principles are always the same. Also, no matter what the model is, the customer always stays at the center of the process. We design with customer’s business needs in mind and try to stay away from the designer-client relationship. We’re all a team in this; including customer, product owner, project manager, and designers — so that there is an enforced clear communication at all phases.
Phase 1: Discovery
The first step of plunging into a design is trying to understand what the customer is looking for and what’s expected of us. It’s important not just to understand the specific design requirement, but also the business goals of customers. We need to know why this design activity is important for the customer and what benefit it will bring to their business. This activity generally begins by gathering all briefs, documents, and ideas from the client. We try to understand the business, the users and what’s expected out of the design. Though we don’t have any visual output delivered in this phase, the findings of the Discovery phase is crucial for the success of the project. We communicate closely with the customer to understand what they wish to do. This mostly happens over meetings (online and in-person) where we listen to them and ask questions. Also, another important stakeholder we consider in this phase are the software developers. It’s important to understand if a design is viable and doable in the available time and budget. The development team helps us set realistic expectations with the customers to make sure we’re not over-promising or under-delivering. Tools: Google Docs, Sheets, Slides, Microsoft Office, Skype, join.me
Phase 2: Project Design
The next step is User Experience design. As soon as we exit the Discovery phase, we begin interacting with the users and try to understand what’s needed to design the system. While we’re understanding a high-level product and business goals in the Discovery phase, we try to consider things like visual look and feel, micro-interactions, page/screen function in the piece of software we’re building in this phase. Every detail accounted for in the research leads us to a phase where we begin drawing up user flows, personas, user stories and scribble on paper. UX Design: The wireframe phase is where we’re drawing out basic user flows, scribble diagrams and taking down notes extensively. This is the most iterative process where we may end up going in circles for days or weeks until we believe we fully understand what needs to be done. The UX phase gives us an idea of how we intend to drive the project and all of the following phases are dependent on how well we execute this phase. We also get a sense of the volume of design deliverables at the end of this phase. Tools: Google Docs, Skype, join.me, Paper and pencil (literal) UI Design: Once we have clarity of what needs to be designed and how we start with creating the visual mockups. This basically is converting the low-fed (paper/wire) mockups created in the UX phase using actual colors, fonts, and images. We’re followers of OS-specific design guidelines but we’re not afraid to break rules either. We use industry-standard tools like Sketch and Figma for the workflow. The output of the UI design phase is pivotal as this is the first phase where our customers “see” what’s being built and can guide us to their taste and preferences. Tools: Sketch, Figma
Feedback and Iteration
The visual mockups are then shared with the client and then starts the feedback round. We’re believers in failing early than late. So if there is a gap in design, the customer steps in early and helps us re-iterate. We’re open to suggestions and love experimenting. Client calls too are super helpful and we like talking to them, however, Invision happens to be our go-to tool to collect, aggregate and track feedback. Tools: Invision, Figma, Google Docs, Skype, UberConference, Join.Me
Phase 3: Development Prep and Handover
Styleguide
Once the designs are okayed by the customer, the next phase is to deliver it for development. But even before we hand it off for development, we need to clean up the design (it gets super messy at times when we’re reiterating) and package it in such a way that dev work can kick off right away. We prepare the redlining document which works as a defined set of styles and rules that developers must follow. This is crucial for successful development of a consistent and cohesive software experience. Tools: Sketch, Frontify, Invision Inspect, Figma Inspect
Animation & Interaction
Something we didn’t do in the past but have started doing extensively lately is accounting for interactions and animation. Animations serve a very functional purpose of providing visual feedback to actions, reduce user’s cognitive load and convey state. We illustrate interactions using animation to help users understand the interface and help developers plan ways of achieving it. Animations have become crucial as a part of our design delivery because a living, breathing UI speaks louder than static image frames. Tools: Principle, Adobe After Effects, Apple Keynote, Lottie
Conversion & Integration
Creating a style guide is not sufficient as the next step is to help developers with the actual set of assets and components required for a software. Since there are multiple projects going on inside Leapfrog, we have to make sure the designs are correctly converted to the target development model. We have a different workflow for delivering assets for a mobile app project compared to delivery of stylesheet for front-end libraries like ReactJS or Angular. Tools: Sublime Text, Atom, Visual Studio Editor
Phase 4: Launch and Post-Launch
Design QA
Once the development team has completed building the software, the design team steps in again and assesses the software. We try to make sure that every component delivered is correctly functioning and if anything has been lost in translation or missed. We QA the visual look, colors, optimization (performance and browser) and interactions. If something doesn’t look right, it goes back to the dev team to be fixed and once everything is signed off from design QA, the software is deployed for the end consumer’s use. Sometimes, an idea that everyone believed would work wonderfully doesn’t come across as expected; partially due to technical constraints or sometimes because it gets lost in translation. We help developers re-iterate over these gaps so that we don’t compromise on anything promised to the customer. Tools: Docs, Spreadsheet
Measuring Success (and Failure)
Deploying and signing off a design project does not end the work there. It is super important to the design team here at Leapfrog that the design is serving for the benefit of the customer’s business. We help our customers determine their performance metrics and ways to achieve them. We help them run user testing, user interviews and perform A/B testing — which leads to invaluable findings. We’re able to see what works for the customer’s users and what doesn’t. When a design (or a component/feature) fails we quickly go back to the design desk and evaluate what went wrong (ie. what is the data saying, what were the users saying) and take corrective measures. There are more cycles of iteration that we validate with users until we get it right. We learn from the mistakes and iterate over them. Tools: Mixpanel, Google Analytics, Interviews, Visual Recording
Constant improvement
The design process forms a perfect circle here where we’re back to where we started to see how things can be scaled up. Customer’s demands grow, requirements grow and users grow in the process of time. This brings about new challenges and duties we must perform to take our design process a step higher. We iterate over our design based on the measurement of the KPI’s and findings of the user research. We have multiple experiences of staying with the customer even after the completion of the project building something bigger and even better.
