# Getting Started
# Principles behind our tools
When you're building a tool for Skyscanner, our users, or our partners, there are some core principles that you should follow. Even the smallest tool can benefit from adopting these principles, and they'll mean that your app will easily scale up in future.
# Universal
Our consumer apps are used by millions of people across the world every day, and whilst our tooling doesn't have the same size of audience it will still have the same breadth.
You may choose to launch your tool with one language supported, but your app shouldn't be designed in a way that it won't support people in other countries. This can mean ensuring that you make clear what timezone a piece of data is from, or avoiding idioms and market-specific language.
Universal tools are fundamentally accessible to everyone. Accessibility is about building tools and products that can be easily used by people in a wide variety of contexts, with different needs. Some accessibility considerations are required by law, but it's a good idea to follow them anyway.
An accessible product benefits everyone who uses it, whether their additional needs are permanent or situational.
You can learn more about designing for everyone in the Accessibility section.
# Clear
The tools we build can support mission-critical decisions and dense data-sets. By providing clarity and a clear visual hierarchy the people who use our products can always be sure about how to accomplish their tasks.
Clarity extends to the text we use in our interface, using the right words in the right place so that both experienced and new users can understand the product.
You can learn more about writing clear copy in the Copywriting section.
# Empowering
We build tools to help people work smarter and better. Software can help to turn a repetitive task into an automated one, saving us time to work on the things that we enjoy.
The form and function of your app should help to guide people and where possible get out of their way. Help screens and onboarding act as a contextual guide, there to support someone if they're unsure or need more details. Adapt to the device the user is on and understand their context, don't give them a broken experience because you don't want to support a mobile screen. Your app should be logically laid out so that new experiences are familiar and easy to pickup.
Make easy tasks easy and hard tasks possible, what you build should never act as a barrier to people accomplishing their goal.
You can learn more about how to structure your app in the Structure and Navigation section.
# Importance of research
Building a great piece of software means understanding the people who'll use it. Even if you're making something just for you and your team it's important to think as broadly as possible. You may have new starts who don't have the same breadth of knowledge, or existing team members trying to use it outside the office. Avoid thinking of just yourself when you make choices.
# Research methods
Starting research early is the best way to avoid leading questions. The simplest way of understanding user needs is asking questions.
Let's say you're building a tool to help a sales team update partner subscriptions. Ask them about the process, where and when they tend to make the changes. Understand not just what their pain-points are, but the context around the task. Someone may ask you to build them an app, but sometimes the best solution could be a change to something they already use.
As you develop your designs further you should test as often as possible. Paper prototypes are a great way to talk through a planned design before you commit to code. Sketch our your interface and ask your users how they'd accomplish the tasks they mentioned in the previous stage. Avoid leading questions, and do your best to listen - if they get stuck you can ask "what would you expect to happen next?".
Finally once you've got an early version of your product make sure to put it in front of live users. Avoid waiting until you've added every feature, you'll be able to see if your idea is working by testing a Minimum Viable Product (MVP). Just remember the 'Viable' part - your product should at least do what it's supposed to.