We are an agile operation, designed to grow and evolve as we observe the world around us, including our own mistakes. This is where we keep track of our ever-maturing best practices and worldview. We exist to service startups, being the most effective partner we can be. To that end, this content is both public, and evergreen.
Knowledge exists to educate and inform our audience, whether you are a client or just a budding young designer. At Fueled, we aim for full transparency; Knowledge is our way of showing the world how Fueled does things. Our goal is to have every process, methodology and tool explained in plain English. To create a Knowledge post, content creators on the Marketing teamwork with internal teams to document processes in ways similar to how we work on case studies for clients.
The writers on the Marketing team are in charge of making sure Knowledge articles are added frequently and kept up to date. The brainstorming process begins every time we write new content. Whether it be a blog post, case study, or landing page, we comb through our work to identify any key phrases, programs, or ideas that may need elaboration. These we bring to Knowledge.
Every Knowledge article is specific to each of Fueled’s departments- Business Development, Operations, Accounts, Marketing, Product, Design, iOS or Android Development. The process begins with a content team member chatting with a department head or specialist who can elaborate on a topic and walk them through what Fueled does differently in this field. The writer takes these ideas, and in a coordinated effort with the rest of the marketing team and the respective department, produces all of the wonderful content you see here.
Each Knowledge article is reviewed by all parties involved to produce a concise, reader-friendly result. Our ever-growing expertise and innovative work ensure that Knowledge is constantly being updated and refined.
Each day, more than a thousand new apps enter the App Store. That makes it probably the most competitive market there is.
Not surprisingly, the failure rate of new products today is much higher than ever before. While the costs of launching a new product have gone down, it’s still quite costly to fail.
On the other hand, with all of the data available, you can improve the chances of your product’s success massively, if you can get to market quickly and cost-efficiently and reiterate the process if required.
A Product Design Sprint is typically a five-day process developed at Google Ventures. They’ve been used by GV portfolio startups like Slack, Nest, and Medium.
The purpose of a sprint is to answer critical new business questions through design, prototyping, and testing ideas in the market, with real customers.
Sprints combine the principles of Agile Development’s (fail quickly, fail cheaply) design thinking developed at IDEO and the D.School at Stanford with behavioural science and business strategy.
In other words, instead of spending months and tons of money on product development hoping the market will like it, you get the key answers in five days and end up with a Minimum Feature Set (MFS).
Then, you run another Sprint, improving on the feedback you gained from the previous Sprint(s). This is not a one-off event; it’s a continuous process of improvement.
A typical Sprint takes five days. That includes planning, the actual sprint, finalizing the results, and planning the next Sprint.
Behind each Sprint there's a team of designers, engineers, product managers, and researchers led by a Sprint Master, typically a UX Researcher or a Designer.
Each design Sprint involves the key stakeholders and goes through a six-step process of Design Thinking.
Understand: First, you want to identify key user needs, business goals, and technical capacities. This involves activities like market research, user interviews, and drawing a stakeholder map.
Define: The second step is to define the user journey and get an answer to the question, “What three words would you like for users to use to describe your product?” so that you can clarify your focus and key strategy.
Diverge: This is the creative part of the process. Every stakeholder is challenged to come up with ideas. There’s no judgment; there are no limits.
Decide: At this stage, the team reviews the best ideas and decides which one to prototype. Teams use methods like Thinking Hats to take out the bias and Zen Voting to decide.
Prototyping: Things are getting real here and the idea is turned into a prototype. This can be a mock-up, demo, physical prototype, or video.
Validate: After the prototype is made, you get your team’s assumptions in contact with the reality. It undergoes stakeholder feedback, technical feasibility tests, and actual market feedback in the form of user testing.
You then take what you learned, survey everyone for improvements, and prepare for the next Sprint. The goal is to build a product that succeeds. It’s that simple. Each Sprint is a big step closer.
At Fueled, we take a slightly different approach. We keep the number of Sprints to two (maximum three) to move quickly and cost-efficiently.
There is no typical Sprint. The Product Design Sprint at Fueled is a slot in which you can fit any number of activities that you deem most important to get to a Minimum Feature Set.
The element of flexibility is key since Sprints can be added or removed as dictated by the evolving needs of the project.
Ultimately, we go through the process of ideation, research, and concepts until we find a Minimum Feature Set. Then, we’re confident enough to move onto the next Sprint.
After we’re done with answering the key business and product questions, we move the project to a Design and Development Sprint phase.
These Sprints last two weeks and involve 240 to 320 hours of work by a fully dedicated engineering team, supported by designers, product managers, and account managers.
As development progresses, each successive release will support more features/polish, building upon the prior sprint.
Our goal is to produce a releasable product within 2 sprints. This product is not final; we just build what’s essential to test in the market.
The vision is to quickly capture user feedback in order to refine and iterate upon the product feature set and footprint.
In some instances, our clients require more than a standard Product Design Sprint. As a result, we’ve created an Enhanced Product Design Sprint offering to provide supplementary deliverables, support, and a larger time commitment:
Why are these additional resource hours necessary?
Many of our clients are working with an established business strategy, building on years of recorded metrics. This means working with clients to meet business needs. With these companies, we take a deeper focus on Key Performance Indicators based on existing business metrics. Startups are concerned with growth, and while a Fueled product can grow a user base, we put a greater focus on revenue with enterprise clients. Ultimately, the needs of a client are for them to decide, but we find larger storied organizations require a business plan of action.
Another reason for the Enhanced Product Design Sprint offering is that many larger companies have a complicated backend system and third party APIs to integrate into the final product. To fully ensure we can implement our envisioned feature set, we need resourcing to investigate what these backend systems allow. In these cases, our engineers are resourced for a greater period of time, usually, three times as many hours compared to a standard Product Design Sprint, ensuring the product team’s vision is executable on a technical level. Doing so allows Fueled to deliver a well-designed frontend that functions as promised.
Presenting Product Design work to enterprise clients requires a different approach than in a standard PDS. Larger clients often have a breadth of major stakeholders that typically require different levels of attention and prioritization for our deliverables than a startup would. For these larger clients, our presentations must simply be more refined. With a startup, we can work on our presentations, in recurrent meetings with a majority of major project stakeholders. In an enterprise engagement, many team leaders are involved on the client side. In these cases, our work needs to speak for itself. Not all stakeholders will be present during sprint meetings, so our deliverables need to stand alone. All departments get resourced for more hours, but strategy account management will specifically have a larger role when working with larger clients.
“Make something people want. That's the fundamental problem. If you die, it's probably because you didn't make something people wanted.” Paul Graham
The popular image of entrepreneurship has little to do with the reality. The general wisdom is that behind all great products, there’s a visionary entrepreneur who just “gets it.”
Entrepreneurs often think that if they work hard enough, they’ll build a perfect product that will be a ‘winner.’ “You just have to get it right.”
But that’s not how technological innovation happens.
Trying to build a perfect product that will appeal to many customers will, 99.9% of the time, lead to failure. The reason why is very simple.
You won’t get it right the first time. Your idea will change.
When Harvard Business School Professor Clayton Christensen analyzed a dataset of startups from over the last 100 years, he simply concluded that the startups that succeed are the ones who have enough money left over to try their second idea.
Likewise, according to Paul Graham of Y Combinator, ”In the average Y Combinator startup, I'd guess 70% of the (startup) ideas are new at the end of the first three months. Sometimes it's 100%.”
Most of the product development happens after the launch. It’s the real market feedback and hard user behavior data that leads to epiphanies, and it’s the epiphanies that lead to homeruns.
Instagram started as a Foursquare knock-off that failed. Then they noticed that their most active users loved the photo feature.
Slack was a multiplayer gaming app that failed. Then they realized that their most popular feature was the group chat.
Twitter started as a podcasting company. When that idea didn’t work out, Evan Williams asked asked his team for a new direction. That new direction turned out to be Twitter.
YouTube was a video dating company that failed. The technology it created became a foundation for what later became the second most popular website in the world.
But if a startup launches a buggy product, won’t it hurt its brand? Well firstly, a startup has no brand; even if one million users get disappointed, it won’t matter if you get it right in the end.
Secondly, the idea isn’t to launch a buggy product, but a well executed Minimum Feature Set (MFS) that allows you to get to market quickly and cheaply.
With MFS, you test your core assumptions and learn. No matter how good you are, some of your assumptions will be wrong. It’s just hard to guess which ones. Then, you take what you learned and improve.
In other words, you either validate or you fail. If you fail, you fail quickly and cheaply. Likewise, you move forward quickly and in a cost efficient manner, because with each iteration, you’re in the market learning lessons and getting data that you’d never otherwise get.
That’s the key and most important reason why you should always choose to go with MFS, instead of spending months building a ‘perfect product.’ But there are also couple of other reasons that make this an important choice.
Most entrepreneurs are delusional, or let’s say, ‘overly optimistic.’ That’s a good thing - in some cases.
To convince your employees, investors, business partners, and your parents (just kidding, you’ll never convince your parents) that your startup will be a major success, despite terrible statistical odds, you have to be borderline delusional.
Whether you like it or not, to go through the emotional rollercoaster that a startup typically is, you’ll need to have a biased view of the market, the customer, and product development.
And that can and most likely will lead to failure. What you want to do instead, is to get to market fast, with a Minimum Feature Set instead of a ‘perfect product.’
MFS will allow you to collect real market feedback and real data and base your decisions on it. All delusions simply wither under the light of data.
The Customer
Going all in to build a product based on guesstimates, hopes, and customer surveys is a sure way to fail. That’s because customers and users won’t really tell you the truth unless their wallets are involved.
Just ask any random person whether they prefer Buzzfeed or the New York Times. They’ll choose the New York Times. In fact, I’ve never met anyone who reads Buzzfeed and I have no idea how it gets 300,000,000 visits a month.
The best way to see if your product can succeed is to sell it to someone. Actions don’t lie.
Product Managers (PMs) play a pivotal role at Fueled. From ideation to launch, product managers stand at the intersection of creative, technical, and business stakes and are expected to deliver high quality products on-time, on-budget, and on-strategy. Sounds like a challenging role? It absolutely is. Here’s what’s it like to be a product manager at Fueled.
Products that succeed in the market are built by committed, passionate, cross-functional teams, that include engineers, designers, marketers and so on. You can imagine each product team as a startup. And the product manager is basically the CEO of that startup.
In other words, they’re the glue holding different parts of the team together while ensuring that products get made, launched, and adopted in the marketplace. Strategy, execution, and user understanding are the key functions of a product manager.
Based on the definition above, a product manager is someone who understands each aspect of product development, has great people & leadership skills, and has empathy for the user. To get more specific, here are the skills and characteristics of a great PM:
Generalist: A product manager is the most technical person among non-technical people and the most business savvy person among technical people. Same applies to each aspect of the product development, i.e. design, marketing, data, etc.
Creativity: Product managers play a key role in generating, developing, and curating new ideas. They know how to manage and prioritize new ideas. Then they translate those ideas into a strategy and execute it.
Data-Driven: Ideas are hypotheses; data are a reality. A great PM knows where to find and extract relevant data, such as market feedback or user behavior, and relies on it instead of merely following a gut feeling.
Strategic Thinkers: When you work with multiple parties, you come across many ideas that can lead to different outcomes. One product may succeed in B2C but fail in B2B market. To make the right decisions, PMs need to have a good sense of which ideas make sense to integrate into the overall plan and how to go about testing and executing them.
Leadership Skills: Among the top characteristics that make a great leader is the ability to collaborate and communicate. Product managers make everyone work together and get things done. That involves internal teams, external parties, clients, users, etc.
User Science & Empathy: No matter how clean your code, how beautiful your design is, or how well your team collaborates, ultimately it’s the user that makes a product a success or a failure. Great PMs can put themselves in the user’s shoes, understand their needs and feel their pain from the very beginning of the product development process.
They Get S**t Done: Getting s**t done means delivering high quality, on-time, on-budget and on-strategy.
PMs are involved in product development from the very beginning of the process when the client signs the Letter of Engagement. From ideation to market launch, they drive the product development through each of its phases. These are:
The Kick-Off starts after client signs the Letter of Engagement. The ultimate goal of the Kick-Off is to identify the problem a client is trying to solve and formulate the smallest experiment possible to test underlying assumptions.
Product Design Sprints (PDSs) are sets of one-week Sprints, focused on ideation and concepting, and eventually its outcome is a feature set you feel confident enough about to move into the design and development phase.
Design and Development Sprints (DDSs)last two weeks. The ultimate goal is to produce a releasable product within 2 sprints. As development progresses, each successive release will support more features/polish, building upon the prior sprint.
Release is the result of DDSs. This product is not final; we just build what’s essential to test in the market and quickly capture user feedback in order to refine and iterate upon the product feature set.
Here’s a how the job looks like in brief. The kick-off is where you become familiar with the industry, client, and the problem they’re trying to solve through a range of activities like competitive analysis, market research, and preliminary ideation.
Together with an Account Manager, you act as the client point of contact and work closely to ensure your team delivers both a successful product and a satisfied client.
The PDS at Fueled is a slot in which you can fit any number of activities that you deem most important to get to an Minimum Feature Set. That’s where your strategic thinking comes into play.
Your aim is to define the assumptions around the problem, the users, and the market, and to deliver wireframes, customer personas, competitive matrix, market data, and insights in order to set everything up for the DDS phase.
During the DDS, the team produces a releasable product within two sprints and PMs then prepare requirements for the launch of a product, such as beta testing checklists, KPI definitions, and so on.
After launch, you manage the the data collection and analysis, market feedback, usability tests, and iterations towards the ideal outcome.
Before any work is done on a project, please request that the Account Manager of the project sets up, and shares everyone involved on a Dropbox folder.
Dropbox folders should be set up in the following manner:
Client Name
[Client Name]-[Job Number] [Job Name]
Account Management
Assets (Any pre-existing product assets go here)
Client Supplied Documentation
Design
Assets
Flats
Fonts
Icon
Motion
Presenter
Slices
Source
Development
Wireframes
This organisation lets us keep track of all the moving parts in a design project. If you’d like to see an example project, just ask.
When you upload files and folders to the project Dropbox, we have a few naming conventions to follow so people can easily search for particular files in future.
The Client Name and Job Number should be obvious from the Dropbox folder you’re within.
The Task Name is relevant to the file of folder you’re uploading. It might need to be named Design-Concepts, App-Icon or iOS-Presenter – these names are quite flexible, but should always make sense and be easy to search for.
The version number should be applied from the beginning so when any amends are carried out, we can archive the old file or folder into an /OLD folder in the same directory. This lets us keep track of the most up to date designs.
To keep our Dropbox syncing times to a minimum across our various offices and home devices, please .7z any large files (mainly .psds and .sketch files).
This includes the latest work on our brand, any brand assets or templates you may need and formatting options around documentation. It also houses links to our stationery and photography, as well as our website files.
The design internal folder is a staple part of any designers day, it includes a whole host of assets from stock photography and icons, device templates and GUI guides, through to our team avatars and big brand logos.
At Fueled, we follow Agile. Our mission is to build great products that succeed in the marketplace instead of running an on demand factory.
With traditional software development process, you ask your client for the product specifications, you build it up, charge their card, and wish them luck. That’s not how you build the world’s top mobile development company.
To build successful products repeatedly you need a process. There’s no secret sauce or know-how many companies claim to have. It’s a process of ideation, discovery, testing, and iteration.
That’s because with each new product, you’re entering a completely new and unique market reality. You won’t learn about it at school and you can’t just guess it. The only way to find out is to ship a product and get hard market data and user feedback.
And that’s what Agile is about. You build a product iteratively and incrementally. You ship fast and often, get feedback, and use it to improve.
The incremental nature of Agile allows us to save a lot of time and, ultimately, the client’s money, as you only build what’s necessary. That matters. Software development is the most expensive part of the shipping process.
Agile manifesto was authored in 2001 with the simple aim to deliver better software. The existing processes such as waterfall development had the same objective, but the results were not often the same.
The 17 authors had all different ideas, but they agreed on four principles:
Individuals and interactions over processes and tools We love processes and we love our tools. But great work comes from great teams. Great ideas come from people. Thus, instead of relying on processes and tools only, we choose the processes and tools that empower people and allow them to express their talents and skills.
Working software over comprehensive documentation Instead of writing up lengthy, detailed specifications, we focus on shipping software fast and frequently. That’s so we can put it in the market and get the valuable feedback on what matters in the product and what doesn’t.
We do write documentation. We just write it when it has value.
Customer collaboration over contract negotiation Contracts are important. They stipulate what’s to be done and provide security. But what’s the primary reason for a client-developer contract to exist? It’s to deliver a product that works from a technical standpoint and in the market. Thus we’re not looking for a false sense of security. The customer-developer relationship works much better when the two work as partners and collaborate on the ideal outcome. In practice, that means we build a high-level of flexibility into the way we operate.
Responding to change over following a plan We value planning, but most planning is based on assumptions and educated guesses. But throughout the process of product development, reality unfolds. The target customer may be someone else. The market sentiment may change.
There’s no point in delivering on specs, once the original assumption prove to be obsolete. So while we do plan, part of the plan evolves in response to actual data.
Prototyping is one of the key steps in product development. Yet, it’s something that can be quite confusing to not just clients and entrepreneurs, but designers and product managers too.
Let’s dive into what prototyping is and how we do it at Fueled.
To put things in perspective, we begin with a great comment by Balaji Srinivasan of Stanford, which we’ve slightly modified: An idea is not a mockup A mockup is not a prototype A prototype is not a minimum feature set A minimum feature set is not a product A product is not a business And a business is not profits
When building a product there’s a process. You go from an idea to a working product to a revenue with margins.
Throughout that process, things can go wrong. Your idea may be wrong, the product may not be usable, the market demand may not be what you expected, the pricing may simply not work.
As an entrepreneur or a product manager, your goal is to make sure those things don’t happen. And prototyping is one of the steps in the process to ensure it.
Its purpose is to simply evaluate the idea. It’s designed to determine feasibility but does not represent the final deliverable. The process of prototyping should trigger new ideas and determine which direction to take.
Our goal is to build products that make a business sense. That means if a client is, let’s say, a startup entrepreneur, his or her ultimate goal is to build a sustainable business. Building a pretty app or even a popular app is not enough.
There’s a lot of failure in the business world. In fact, the vast majority of apps are not financially successful.
To build financially successful products, we follow an incremental process during which we aim to eliminate most of the variables that can lead to failure.
Instead of just getting client’s specs and building a product accordingly, we build numerous versions of the idea/product designed to uncover variables and find the right direction. They include:
Sketches: Sketches are simply a raw hand drawing on a blank piece of paper. It’s a quick way to get your idea ready for brainstorming and visualize what a client has in mind. A simple sketch is better than words.
Wireframes: A wireframe is a simple structure of your design scheme. It answers the crucial layout, feature structure, and organization questions before you get into the design and UX stage.
Mockups: Mockups are the visual representation of the app. They answer key design questions such as color scheme, branding, typography, style, and so on.
Prototypes: Now what you know the structure and the design, it’s time to add some interactivity. That’s what prototypes are about. They’re not the product ready for market, but they represent an interactive version of the product to demonstrate user flows in order to catch any errors early on.
Minimum Feature Set (MFS): Minimum feature set is basically a product ready for market, but not the final version of it. It contains just the features necessary to test the core business and product assumptions to see if they validate. If they don’t, you get the user feedback and use it to iterate the process.
Product: MFS is designed to test assumptions, collect data and improve on facts rather than hopes and dreams. After some successful iterations, you get the final version of the product, the one that solves the customer problem so well they’re willing to pay or use the app regularly.
The process is quite simple. We build products iteratively during several Product Design Sprints (PDS) and Design and Development Sprints (DDS).
Once we meet the client, we do some initial research and brainstorming. That’s the stage when sketching takes place. We evaluate core assumptions and do initial market research.
Then we move to second PDS when we begin wireframing the main user journey. Once that’s completed, the design team takes over and creates mockups - visual versions of the product. The branding is usually done in a separate branding sprint without a product manager.
Then, in the next stage, initial prototypes are created using InVision. Depending on the need, it’s either simple prototypes or more detailed boards.
Then the project moves to DDS stage, the ultimate goal of which is to build an MFS and put it on the market. And that’s where the real learning begins.
Used by the accounts and operations team to set out the team’s weekly assignments. It gives us the opportunity to see where people have free time available for new work, and when they’re over-resourced and time needs to be better balanced. Resourcing calls are done each Thursday by your team leads to figure out where to direct your efforts. If there are any outstanding pieces of work you think need to be catered for on your calendar, please let them know.
Used to log our working hours accurately so realistic billing can be made by the accounts team. Under each job you can log the type of task (e.g. UX, Design, Branding, etc) you’ve performed. Due to our sprint model, you may need to request to be added to the latest sprint number on Harvest at times. Please ask the Account Managers of your projects to add you to the right tasks on Harvest.
Please make sure you’ve submitted your hours at the end of the week or on Monday morning, as the accounts team in New York will need accurate info at the start of their day in New York.
The team is split over a few countries, with many other departments.
Operations – In the New York office, overseeing how the company is run, what projects we have in the pipeline, and planning who and when will be involved on those projects.
Business Development – In the New York office, generating new leads and cultivating existing relationships to secure us work and other opportunities.
Accounts – Mainly in the New York office, account managers organise project schedules and clients to keep projects running smoothly and support communications within project teams.
Product – In the New York Office, coming up with solutions to business problems and figuring out their feasibility with the resources given, and working closely with the design team on the correct user experience.
Development – Formed of many sub-teams, development is split across New York and Noida, with satellite offices in Bordeaux and Novosibirsk, and some members in London. They work on our iOS, Android, Backend and QA projects.
The design team is structured into three sub-teams that report to the Creative Director. Each sub-team have specific strengths that best suit the projects Fueled are taking on, and this categorisation helps determine who is best to work on particular tasks.
Product Designers – Responsible for working closely with Product Managers to conceptualise a product’s purpose and user experience. They’ll be heavily involved in wire-framing, user interface design, motion and interaction prototyping, and elements of branding.
Brand Designers – Responsible for our larger branding engagements where a thoroughly considered identity is needed prior to assembling a working product. They are also heavily involved in product design, ensuring a strong is present and consistent with the intended messaging of a product.
Front-End Developers – Responsible for design and implementation of our web projects. They are specialists in knowing the feasibility of our designs, and implementing them in creative ways to make innovative web experiences.
There is a lot of cross-over in assignments for all 3 teams. They are not limited to purely working with their specialisations; they will be resourced to expand their skill-set and try new disciplines.
Client calls are frequently organised for the design team to get an understanding of what the client want and what their thoughts are on work created for them. When possible if you would like to chat to a client, ask the account manager of the project and they can organise it.
If you haven’t frequently been involved in client meetings before Fueled, there’s a few principles to stick to:
Punctual – Please be present for any client calls you’re invited to - if you can’t do the meeting (e.g. too late, or you have something come up) please let the account person know ahead of time.
Relax – This is just another person, you’re not in front of a crowd of people, and talking through your work is just like talking with any of the rest of the Fueled team.
Prepare – If you have particular work to show or questions to ask, just have a think about how you want to stagger the discussion.
Civil – It’s best to be polite and calm even with difficult clients. If you have any disagreements with their thoughts, talk through them your ideas step-by-step so the client can get an understanding of where you’re coming from.
Positive – Be positive when explaining your ideas; clients warmly accept thoughts when it’s clear designers believe in what they’ve created.
Defer – If a client asks for a particular deliverable, deadline, feature, etc - defer to your account or product person to speak about that. You’re not expected to set deadlines; that has to be calculated in accordance with how we resource our team members.
We’re pretty happy to accommodate you putting in your 8 hours a day whenever suits you, but it is best to think about how this will impact you working with the rest of the team. We generally have two categories of when people work:
9-5 – These people start at usual work hours and clock off on or around 5. This usually means you can’t make the later calls with anyone working in NYC, but we generally work around that 5 hour difference by scheduling them earlier.
11-7 – These are the late risers that stay until the evening. This is fine but please ensure the people you’re collaborating with are aware. Ensure work is still checked by your senior/primary designer before sharing it with a client.
If you need a few hours booked in here or there for personal time (Doctors, Family, etc) just let us know and we can rework your schedule around it.
Show creative thinking working alongside a Senior/Primary member of the Design Department, always striving to innovate and create your own work. In most cases you will be paired with another designer to collaborate with and bounce ideas of – getting another perspective and using someone else’s experiences is key to learning.
Aim to maintain the agency benchmark for quality of work output for existing and new clients. We want to maintain a standard of work that clients expect; anything that pushes us beyond that will only make us better.
Be adaptive and always strive to step out of your comfort zone and experiment in new disciplines. You may find yourself getting into facets of design you didn’t expect to, which will end up making you a more rounded designer. If you feel you’re not confident enough to step into particular areas, we can have you working alongside experienced members to help you learn.
Working with the Production Department and other members of the Design Department. It’s key to chat to your account managers, product and developers throughout the life of a project to keep everyone informed and collaboration strong.
Take on board and follow internal processes and protocol. We will at times adapt our process to improve efficiency, ease frustrations and better our design team.
Any other additional duties as requested. Internal projects may sometimes be handed to you to help out in a new area which goes beyond your usual duties.
The design team uses Sketch in most web and application design scenarios. If you need a license key to activate Sketch, please ask your sub-team lead for the Fueled team license. There are some general workflows that’ll make life easier when using Sketch that we adhere to so any design team member can understand our design documents:
Workflows:
Use Pages to map out separate flows, e.g. 1. Onboarding, 2. Sign Up, 3. Log In, etc.
When in the design stage, have a page dedicated for UI Assets, so you can lay out all the assets you will be using throughout the app. This is useful for maintaining consistency and slicing assets.
Use Styles on objects that will share a common style - just be wary when updating these, it will affect them all.
Use Symbols on icons and anything else that will be repeated throughout the app, so changing that asset in future once applies to all.
Use Text Styles to create consistent text styling through your design.
If you want to create things that can’t be achieved in Sketch (e.g. photorealistic iconography), feel free to do that in Photoshop and bring in the exported .png. The same deal applies to working on vector iconography – you can do that in a separate Illustrator file, and copy and paste the vectors into Sketch.
Illustrator is widely used for any illustrative aspect of a project. Anything you create can easily be pasted or imported into Photoshop or Sketch, so it’s fine to work up your supporting assets such as drawings, icons, or branding elements within Illustrator.
It is the preferred tool of choice for branding projects. The design team always creates logo concepts in Illustrator initially, and then imports them into presentation documents for client display.
It is ideal to have the following panes displayed in your workflow:
Layers – So you can manage your layer stack and groups.
Transform – Apply any numeric transformations with ease. You can use Maths in the input fields (e.g. X Pos: 200 + 100px).
Swatches – Manage your colour palette.
Graphic Styles – Keep particular styles consistent across shapes, e.g. if you the same drop shadow on each object.
Stroke – Useful for adjusting the weight, alignment and direction of strokes.
Pathfinder – Performing merging of vectors, divisions, crops, etc.
Artboards – Navigate between different artboards you’ve created assets on.
Gradient – Apply and alter the direction of gradients on shapes.
Photoshop has been relegated to our second choice for most of our design projects. We use it when requested by the client or it makes sense to integrate into any existing .psds for a project, or if we will be handing it off to another design team that uses Photoshop. It is also used for any heavy image modifications we need to perform that Sketch cannot handle.
It is safe to assume that most projects you will be doing will be done in Sketch; if you have cause to question what app we use, e.g. we’re collaborating with a large company with existing designs, please discuss this with your team lead.
At this moment in time the team is using Adobe Photoshop CS6. In the circumstance you do need to design in Photoshop, design at a level of 1x.
We have a Slicy app license to help with exporting retina sized assets from Photoshop CS6. Contact your senior designer for the license key for this.
In Photoshop, name the layers or layer groups you want to export using this format:
InDesign is mainly used for print and presentation documents.
At this moment in time the team is using Adobe InDesign CS6. Please use this version as updated InDesign files cannot be read once modified.
When creating documents keep in mind whether you should set the document up for CMYK (Print) or RGB (Screen). You can modify this in Edit -> Transparency Blend Space.
When exporting documents, as most of our work is digital, Adobe PDF Interactive should be your file format. This will ensure it is formatted for RGB.
When choosing the right app developer for your project, having a clear picture of their product development process is critical. But so is knowing the less sexy details such as communication, invoicing, and budgeting.
It’s the mechanics of the client-developer business relationship that can make or break the creation of an awesome product. Here’s what clients can expect with Fueled.
We use Slack. It’s our team messaging and collaboration tool that we use on a daily basis for both external and internal communication.
For external communication with clients, we open channels for ongoing communication about their project. This is important. There’s always an ongoing discourse between Fueled and the client so we can make sure that the client’s needs and expectations are 100% met.
In addition to Slack, we organize weekly standup meetings. We do them over Google Hangouts or, preferably, in person. All parties are usually involved, though it depends on current requirements.
Standup meetings are organized on a weekly basis, although this frequency may vary on a project-by-project basis or by the project phase. They keep everyone in the loop about important developments and allow the team to quickly respond to changes.
Once a project is moved into development, our product and development teams use Jira, the agile project management tool that allows us to collaborate in a fluid, real-time manner.
Over the course of the engagement, we present design mockups and comps with InVision, a design prototyping platform. General project files, design assets, and project code are provided in a Dropbox folder that is created by our internal team and shared with the client.
Our Resourcing Manager will hold standing weekly meetings with leads from the Development, Design, and Product teams to finalize project assignments for individual team members for the upcoming week.
Resourcing decisions are made a week ahead, and we require a deposit in advance from our clients in order to reserve resources.
The invoicing aspect has two elements. There’s the deposit and there are invoices. The deposit is paid prior to project kicking off and, usually, it’s worth 2 weeks of work. Based on the client’s preference, it can be used to pay out outstanding invoices at the end of the project.
Then, we send out invoices a week ahead of work to be done. As it is with deposits, our standard terms are net-14 days. This one-week buffer allows us to ensure flexibility and consistent progress even in cases of client being one or two days late in payment.
Once we define what the feature set of a Minimum Feature Set (MFS), we’ll get an idea of what it costs to design and build. Since each product is unique and the cost of innovation is unpredictable, the figure is simply our best estimate.
Fueled works on an hourly basis. Thus, the way we structure our agreements reflects that in two ways. We estimate the budget and time required to deliver the minimum required features, and we assign a team to do that. Then, we plan to meet the defined scope.
As a result there’s no fixed-budget and fixed-scope engagement, simply because by fixing both the price and the scope, the only variable left is the software quality. And we don’t compromise on that.
We do, however, engage in bi-weekly strategic planning sessions to make sure we’re clear on progress and to help each team better determine what can be done more efficiently and which tasks may require more time.
Our mission at Fueled is to make great ideas a reality. Therefore, we understand and empathize with the need for budgeting flexibility. Especially with startup clients. For that reason, we created Fueled Ventures.
In 2015, we invested more than $1.5 million into our client companies including Matador, Superhuman, Walc, and Moodelizer. The way it works is that we provide discounts in the form of cash investments or a royalty on app revenue.
The unique and particularly awesome thing about it is that we vest all of our agency staff into the Fueled Ventures portfolio. As you can imagine, this is one of the main reasons we attract and retain the best people out there and keep everyone supercharged to make your product a massive success.
Even when the work is completed, there are costs to maintain the app. You should absolutely consider the costs of hosting ($200 - $600 p/m), getting an Apple developer license ($99 p/a), and whatever the cost of integrated services is. For example, if you have an app that integrates a messaging service like Twilio, the additional cost is $50-$100 p/m.
Then, there are all the other aspects of running a company or marketing a product within your existing portfolio. These include marketing costs, hiring a developer, and so on. This will vary case-by-case as different products exist in different markets with different requirements. In any case, it’s something you should carefully look at while preparing your business planning.
From years of teaming up with enterprises from London to Hong Kong, we have sharpened our ability to collaborate across time zones in a smart, agile way. Facilitating projects with a team halfway around the world isn’t easy, but our product and account managers know how to make it work.
Having spent years building and improving systems for managing projects across time zones, we can seize exciting opportunities with international enterprises and develop their products through smart, streamlined collaboration.
At Fueled, when our project and account managers are working with an overseas client, they do much of their planning at a micro level, which is key when approaching transnational collaboration. Like most teams at Fueled, we plan projects in two-week sprints, but when our team is separated by different time zones, our account managers and project managers have to focus on scheduling day-to-day rather than sprint-to-sprint. Each day, they check all team members’ schedules and make note of where everyone is and what their plans are for that day. We think of them as the people who run forward ahead of the team, trying to clear potential obstacles.
Communication is the key to making the agile process work at any distance. When working across time zones, our team leaders need to be as transparent as possible, which is why they plan ahead by setting up scrum times when everyone can be online. Scrums are meetings to discuss progress, planning, and sprint goals that can take place either on Slack, or on phone or video calls. With the exception of these scrum times, working independently is inevitable when dealing with a time difference. This is why account managers (AM) and product managers (PM) make it a priority to empower the authority of each individual team member— encouraging them to make decisions and keep product development moving forward.
One of the most important ways our AMs and PMs hack project management across time zones is with communication. We use Slack to keep in touch with everyone. At the beginning of every project, we invite our international client to join the project’s Slack channel along with our Fueled team so AMs and PMs can get constant updates on everyone’s progress. Slack makes collaboration simple, because it is accessible both via desktop and mobile, making it super easy to share ideas and stay informed on the dev process. However, this doesn’t always happen automatically. Our AMs and PMs enforce the importance of sharing updates on Slack with the international client, because they may not be as familiar with the tool.
Our AMs and PMs live and breathe Jira: It allows them visualize all the tasks for a given sprint into tickets. Each ticket outlines steps that devs need to take, and can be moved around to swimlanes such as “To Do,” “In Progress” and “Shipped.” Jira is a solid tool for working across time zones because it allows for full transparency among team members, and gives AMs and PMs the ability to track and coordinate progress.
InVision is another great tool that allows for easy team collaboration, helping our designers implement and accept feedback. InVision boards provide a space to share files and collaborate with team members throughout the entire design process. We always share our boards with international clients so they can easily leave feedback on our designs and download files.
Our dev and design teams have developed hacks to quickly share information with overseas team members. On the dev side, we use a tool that automatically integrates code, and allows the international team to pull progressive code reviews.
On the design side, we’ve developed a tool that automatically updates Sketch files to a shared InVision board. We have chosen to use this system of automatic information sharing because it streamlines coordination and ensures that all members are receiving accurate up-to-date information. This keeps the team on the same page despite the time difference.
