Hello, and welcome to our Playbook! As part of our commitment to transparency, we’ve decided to put all of the information about Hanno into a single place so that clients, shipmates and future collaborators can benefit from everything we’ve learned.
There’s a lot of content in here—it’s the ever-evolving instruction manual our team uses to run great projects. And it’s the key to our success. By getting it out in the open, we hope it can help others to improve the way they work, and help future clients and teammates to get up and running on our projects as fast as possible!
Pick a heading, and let’s get started:
We’re a fully remote design team. We build digital products that grow and scale startups. Recently we’ve been using our startup expertise to help big businesses to innovate, explore new markets and work in a more purposeful way.
We operate as a social business (similar to a B-Corp). We believe that design has the power to amplify and accelerate the good that socially motivated entrepreneurs are doing. Now we’re actively looking to invest our time and use our design skills to help them solve major problems related to the environment, education and healthcare.
So what does being a social business entail?
- We are ceasing to be a profit-maximising company. We define success not in terms of profits, but in the progress we make towards solving social problems.
- But we are not a charity. We are financially self-sustainable and don’t rely on grants and donations
- We don’t deliver dividends and returns to investors or shareholders. Money is paid to our team in return for the work they do for the company. Any remaining profit is reinvested in the business itself or in the social startups we help, with the aim of increasing social impact.
In addition to being a social business ourselves, our goal is to accelerate other social businesses and startups. We aim to enable and multiply social good by others, in order to make the biggest impact possible.
As of August 2015, our top 3 business priorities are:
- Find a solid financial footing: Continue to win quality clients which are compatible with our ethos, so that we can transition to social good. Build funds and ensure financial stability so that everything else can follow.
- Build a reputation for world-leading remote design: Build our expertise and reputation steeply. Become a team which is named by others as being one of the best in the design industry, especially when it comes to designing remotely.
- Make a social impact: identify exactly how we will identify and change systems in need of change, and accelerate other social businesses. Take major steps towards making this happen.
New projects come about when the client fills out our contact form form. We have a Zapier hook, which adds the enquiry as a task inside our Pitches project inside Asana. Pitches are sorted according to their current status: iceboxed, paused, qualifying, negotiating. The whole team is added as a follower to the ongoing pitch, so they’re kept informed.
In order to progress, enough members of the team must express interest in the project for us to think we could assemble a team to work on it. If there’s no team interest, we’ll apologetically decline the lead. Where appropriate, we’ll offer a suggestion for where they might look next.
If the initial team reaction is favourable, we’ll line up a video call with the lead. For us, it’s important that this is a video call and not just an audio one, so that we can get to know each other better. This isn’t a kickoff call, and it shouldn’t be with the lead’s entire team.
Here, we want to understand the client better, and hear their ambitions for their project. Just as they need to make sure we can deliver, we need to do the same on our side.
Some key questions that we’ll discuss:
- Find out why. Why did the client contact Hanno—why do they feel that Hanno would be a good match?
- Discover their vision. Gauge technical expertise and level of expectations. Do they sound smart, focused and knowledgeable about their goals and business? A lack of technical expertise is a solvable problem, but needs to later be factored into budgets, for increased project time and more thorough training.
- Understand a little more about their requirements. This is not a deep scoping session, yet, but we’ll likely need to fill in a few gaps in our knowledge and understand a little more about the work that’s required. This will help us to understand the team that’ll be needed for the project.
- Discover their level of commitment. Who will we be working with—who will be the product owner at the client’s end? This shouldn’t be the CEO.
- Sound out their budget. Be accepting of a degree of inexperience—not all clients know exactly how much this will cost. But be very cautious if their budget expectations are vastly out of sync with what’s required for the project to succeed. Squeezed budgets don’t allow the time and thought to deliver great results, and we should make sure we don’t put ourselves in a position where the client might be left unhappy at the end of the project.
- Discuss a very loose timeline. Ahead of the call, the team will check out our upcoming project schedule on Forecast to see what our availability is. But we won’t commit to a project deadline or set schedule on the call, because this will need to be discussed with the rest of the team beforehand.
Team members should be careful not to commit to specific dates in early client calls, so that the client isn’t disappointed when these dates are investigated more deeply and turn out to not be achievable. Be aware that getting through the early stages of contract signing and invoice payment can be more time-consuming than you might expect.
After the call
The shipmate(s) involved at our end will report back to the rest of the team with a summary of what was discussed.
They’ll also make a preliminary recommendation to either accept, or reject the lead—gut instincts are important. Again, enough team members must be willing to take on the project. If they’re not, we’ll regretfully decline.
We may also decline the project if we feel that while the client is keen, Hanno wouldn’t be the best choice for the project. We want to help all of our clients achieve their goals. Sometimes, we’re simply not the right team for the job. If there’s a product or service out there that would be more suited to a client’s budget, we’ll tell them about this, even if it means we’re giving up a potential project in order to save the client money. We feel that’s an ethical route to take, and will leave everyone in a better position in the long-run.
We don’t respond to RFPs. We are a small team striving to deliver value to clients, particularly those we are working with already. Writing extensive pitch documentation and responses to RFPs takes valuable time away from our existing clients and would require us to significantly raise our rates.
We should make the client aware that we adopt the same approach as Paul Graham:
“A lot of would-be startup founders think the key to the whole process is the initial idea, and from that point all you have to do is execute. Venture capitalists know better. If you go to VC firms with a brilliant idea that you’ll tell them about if they sign a nondisclosure agreement, most will tell you to get lost. That shows how much a mere idea is worth. The market price is less than the inconvenience of signing an NDA.”
Be aware that this may require you to educate the client and help them to understand why we take this position.
We respect the confidential information of clients and don’t treat it lightly when they submit an enquiry to us. When we start a project, a full NDA and relevant confidentiality clauses will be included in our contract. But we won’t sign a full legal NDA simply to hear a project brief.
We ask that at the beginning of the process, clients find a way to communicate their project brief with us without requesting that we sign an NDA.
Will you work with my competitors?
We work in the services industry, and with a lot of startups. To agree to an exclusivity clause would require us to charge an extremely high fee.
We do, however, respect confidential information at all times and won’t disclose any of that to anyone else we work with. Where possible, we will try to avoid placing the same shipmates on projects with similar clients.
Scope and billing
We price and bill projects on a flat weekly rate, according to the number of team members who will be required.
If we’ve been able to gain consensus for the project and assemble a team, we’ll send over an Engagement Summary, which sets out:
- The number of team members
- The number of weeks being booked for the project, and the start date for this first sprint
- The broad project goal
- The price per team member, per week
We are a UK incorporated company, and so all invoices and rates are in GBP and will have VAT added on. Invoices are automatically sent out weekly, every Wednesday, with net-14 payment terms.
We’ll also send the client a link to our business details form. This is a form attached to a Google spreadsheet. Once they complete it, it will automatically create profiles for them inside Xero (our billing platform) and inside our other apps.
The Consulting Contract
We have a standard Consulting Contract, which we send out to the client from our HelloSign account for e-signing. Contracts are stored in Google Drive. The contract will be signed by both the client, and our company director, Jon.
This Contract is purposefully broad, and suited to the type of project we work on. It won’t include any detail about the client’s specific project. It’s also applicable to any Engagement we work on together. This means that once it’s signed, we can schedule sprints without needing to sign new contracts each time.
The contract covers basics such as:
- Confidentiality and non-disclosure
- Legal liabilities
- Billing and payment terms
- Engagement terminations—the Engagement can be ended by either us, or the client, giving notice before the end of a sprint week. The Engagement will then end at the end of the week.
Our contracts are under the laws of England and Wales, and any legal action has to be taken in this jurisdiction. This is an important ‘dealbreaker’ term for us, which we won’t change, since it is required in order for the project to fall under our Professional Indemnity insurance. If this is a dealbreaker for the client, too, we’ll have to decline the project.
All our projects are billed and scheduled in weekly blocks. Sprints run on weekdays from Wednesday-Tuesday. We choose these dates because we want to avoid shipping on Fridays, and kicking off sprints on Mondays, both of which are very undesirable.
Before booking a project sprint into our team schedule, we will send an upfront invoice for the first week of the sprint. This is the only invoice we send which is not on net-14 payment terms—rather, it is due ASAP.
During discussions with the client up to this point, we’ll give them approximate estimates for when the project might be able to be scheduled. However, no dates are fixed until we have a signed contract, confirmed Engagement Summary and the first invoice has been paid.
How We Operate
Flat and Open
Our company is a transparent one—every core team-member has full visibility of company finances and cashflow, via periodic team-wide updates, and weekly billing updates. Salaries and pay are also visible to the whole team and each shipmate chooses his/her salary.
We’ve created our own design thinking wiki in which we openly share the tools and processes our team uses during sprints. Since then we’ve come a long way and have also figured out how to use design thinking remotely.
Joining the client’s team
We are a remote team—to be a high-performing member of this team, you need to be an excellent communicator.
We don’t see a place for the old-school ‘design agency’ in today’s world—times have changed. We know full well that the old, broken, waterfall-based model just isn’t compatible with the way good companies work, these days.
We are unusually hands-on with our clients. The goal on every project is to fit together seamlessly with the client’s team, to collaborate, teach, and work towards shared goals. That includes onboarding our client on our project’s team IM conversations in Slack.
The workday for a shipmate at Hanno is 8 working hours—while in rare situations it may be a little longer, this is the goal we hold ourselves to. If any shipmate is consistently working longer than this, that indicates that there’s a problem to be resolved.
As a team, we are highly productive and invest heavily in tools to allow us to be this way. Our philosophy is always that the number of hours worked has no correlation with the quality of work produced.
When working on a project sprint, the amount of time that will be spent on client work will be up to 7 hours (lunch break not included) in a day. The remaining hour in the day goes towards off-sprint work such as internal reviews, research, planning and internal work, all of which allows us to deliver better results when we’re on a sprint.
We work on client sprints from Monday to Friday. Since the team and clients are entirely remote, we don’t stop client work on public holidays. Although it’s rare for us to work over Christmas and New Year.
Full-time shipmates make their own decisions about how much holiday they’d like to take. We try to make sure that everyone takes 35 days a year and that’s usually the basis that most shipmates use to set their salaries. Some decide to take much more holiday than this, but choose a lower salary to compensate for it.
Shipmates announce their holiday plans on Slack to check for scheduling issues. If there are no major problems, they then add their holiday dates into [Forecast](https://forecastapp.com].
There’s rarely going to be a scheduling issue if you’re booking more than 2 months in advance. For shorter requests, it will depend upon sprint scheduling and whether we can find other shipmates or collaborators to help to make up for the absent shipmates.
To minimise holiday disruptions, we ask that shipmates try and plan holidays to avoid departing mid sprint. Since sprints run Wednesday to Tuesday, this means that departing on Wednesdays, and returning on Tuesdays is easiest for everyone.
Working remotely is one of the best-known elements of Hanno culture. It has been the way we’ve worked since the very beginning, and we intend to stick to it. For us, it’s a way to allow our team the flexibility to build great lives around their work, which in turn, helps them to enjoy their jobs more and to be more productive.
We are very flexible about where team members choose to live and work. The biggest requirement is that regardless of where you choose to be based, you must make sure you have an internet connection that’s good enough to handle video calls with clients and the rest of the team.
Team members get login details for our OpenVPN servers—we have several of these, spread across a few different global locations in Ireland, Singapore and the USA, so that the whole team has a fast and reliable connection. VPN usage is compulsory whenever you’re working on public wifi.
Several of our team members are nomadic, or at least, spend several months of the year travelling. This isn’t a problem for us—we simply make sure that they do their relocating while off-sprint so that it doesn’t interfere with client work at all.
Periodically, our whole core team gets together for team trips. The destination for each trip is put to a team vote a few months before we depart. So far, we’ve visited Spain, Croatia, Malaysia and Hong Kong. Since we rarely see each other face-to-face, these trips are a really important way for us to spend time together and learn how to grow and improve.
Our current team trip format is for the trips to be around 9 days in total. This includes 2 weekends, which sandwich a 5 day week, where we work on internal projects and hack weeks.
During the team trip, we’re unavailable for client work, and we schedule client sprints accordingly, to give us the time and space to make each trip a big success.
Where we feel it would help us to do a better job on a project, we may bring in collaborators to help us. These contractors will be booked on the same, weekly basis, and will become full-time members of the project during the booking.
Confidentiality of project and client information is important, so each of these contractors will sign a standard Independent Contractor Agreement. This will be sent out from HelloSign, and sets out our standard confidentiality terms, along with other conditions for working on the project.
We’ll also send a single booking document, which will set out the dates we’re booking to work together during.
Collaborators will be added to the project management tools (such as Asana) that they need in order to carry out their roles.
We use Slack for internal chatter, including marketing discussion, and general chat between shipmates.
We are huge fans of Asana and use it to manage the majority of on-project internal discussions, and anything that requires a task to be completed. We also keep open an internal Basecamp project called Hanno Team News, into which the team posts occasional discussions, and also financial updates and planning.
We have an internal rule: default to Asana. It’s very rare for anyone on the team to email each other.
As for the tools we use for each project—that really depends on the project. We’ll often use Asana to run projects, but if the client has a defined workflow and we need to integrate into it, we’ll switch from anything from GitHub issues, to apps such as JIRA.
We are huge fans of Google Docs. If written communication is not in Asana, it will be in a Google Doc. If we find ourselves writing a long message in Basecamp, we stop, turn it into a Google Doc, and send that link via a Basecamp message or an Asana task.
Internal calls usually happen over Skype—we feel the audio quality is better than Google Hangouts. They are always video calls.
While we understand the need of everyone in the team to be able to hit deep focus, we also believe that teams build better products together than any one person can by themselves. To accomplish this, we make sure that regular team calls are a built in part of every workday.
We have a heavy emphasis on spontaneous pairing within our team, particularly when it’s between people with different skills. This means that designers and developers will often pair to overcome a problem, and daily pairing is strongly encouraged. It helps build up skills within the team, improves code quality, and keeps communication strong on projects. We also feel that it leads to better results because team members can collaborate with each other.
We use Screenhero lots for internal pairing sessions, and also frequently pair on Google Docs.
Performance and coaching
One of our most important cultural values is that we will never settle. This means we work really hard to help our shipmates grow.
We track our weekly Plans, Progress and Problems inside WeekDone. We’ll keep our top 4+ plans for the next 7 days inside here, whether work-based (“ship new marketing copy for Client A”), or personal (“hit the gym 4 times”; “cut down on coffee”) so that the whole team can see them.
We all give support and encouragement to our shipmates, and if someone seems to be struggling, anyone can jump in to help out.
Sure, it feels a little bit like you’re working for a bigger company, but we’re also big on OKRs, which is the tool Google uses to set personal goals and targets. Each quarter, we all write down our personal targets for the next 3 months in areas we want to grow in in our careers, and add them into 7Geese. We’ll then aim to hit as many of these as possible in the next few months.
All OKRs are visible to the whole team, and we all try to coach each other and provide plenty of motivation to make sure everyone is making the time to focus on growing in areas which are important to them.
Each month, during the first week of the month, every shipmate has a 1:1 call (or an in-person chat, if they’re in the same city) with Jon. In short, it’s a chance to have a chat about how the month went, and what else Hanno can be doing to help you grow, and make life better for you.
Ahead of that 1:1, Jon will send brief feedback on the month’s progress, via 7Geese.
What we look for
We look for talented, cross-functional shipmates. Since we do a lot of work with early-stage startups, versatility and a wide range of skills, is important. As is the ability to work really closely with other members of the team, remotely. Location is not a problem.
A new shipmate will typically get in touch via email, to firstname.lastname@example.org. Emails to this address are piped into our [HNO] Hiring project in Asana as a new task, ready for the team to take a look at and reply to.
If we’ve not worked together before, then the first project we will work on will be a sprint together, so that everyone can see how the working process feels.
If the sprint goes well, we’ll talk about what we’d both need to do to make things happen again on a more regular basis, whether that’s as a full-time core team member, or as a recurring collaborator.
We hold fast to the philosophy that great results on complex challenges come from building a great team around the problem. We don’t believe that any of our shipmates should be working solo.
So we build small, cross-functional teams for each project. This means that depending on the project needs, we’ll typically have 3 shipmates working on each client sprint.
We also don’t feel that great work comes when our attention is split between multiple projects. A consistent project team, which doesn’t change on a regular basis, is the best way to build great relationships with our clients and to make sure that team is productive and understands the project deeply. So team members will stay on the same project for the whole sprint, working full workweeks on that project, rather than working on multiple projects at once.
Team schedules are shown in Forecast, and teams are responsible for managing their own schedules and also requesting resources from other team members, as needed. Where possible, we will aim to avoid having sprints run back-to-back. Downtime in between sprints is for internal work, including marketing, blogging, and building team tools.
Where we have an ongoing project that is expected to pause after a sprint completes, and then resume a few weeks or months later, that client should be given priority over any new project leads or commitments. Ideally, we’ll look to give them first refusal on the timeslot before another project is booked into it. However, all available project timeslots are handled on a first-come, first-served basis. The client must commit to subsequent sprints, and organise a booking and week 1 deposit, before that timeslot will be reserved for them.
Our working process is extremely intense. To make sure we can start off at full-speed and deliver value to the client, we’ll send over some research and prep tasks to the client about a week ahead of kickoff. These will cover topics such as:
- The product’s business model (or intended model)
- User feedback on the current product, if it exists
- The company and product history so far
- Key project objectives
Getting solid answers to these questions really does have a big impact on the quality of work in Week 1. If we don’t have this, we will inevitably make much slower progress.
The first day of the project is always a busy one. The aim is to lead into it by getting hold of a set of solid worksheet responses from the client beforehand. Then, as a team, we’ll spend the first few hours looking through all the information we’ve received so far, and leading into a kickoff session with the client.
Day 1 is where we’ll look to get a deep understanding of what the project is going to cover, and what the client has already learnt so far. We’ll work together with the client to set out priorities for the sprint, broken down into weekly milestones. The process of working together to create these stories is important. The entire team (and the client) can all discuss the merits of each feature/task being added to the roadmap.
At the end of this process, we’ll end up with a much clearer project outline and specification, and a good idea of what to tackle first.
We often use Trello for collaborative storyboarding - we like the simple UI and ease of use for clients. It is highly visual and allows us to get them involved in prioritising stories and including some basic agile on the project, regardless of whether we go for a full-blown agile sprint process. We explained this in a bit more detail in a recent presentation, and you can also view an example Trello project to see it in action.
Daily standups and communication
There’s ongoing communication between the team and the client every day—it’s a crucial part of our process.
Every morning, the team will paste a blank Google Doc template called the PPP into the Slack room. This has sections for Plans, Progress and Problems. Each day on the project has its own PPP, and over the course of the day, that document will be gradually added to, by each person involved.
At the end of the day, the PPP document will be edited to be publicly visible to anyone with the link, and then dropped into Basecamp. This way, even someone on the client’s team who isn’t directly involved in the day-to-day decisions, can be kept updated and informed.
We also have regular internal standups within the team—clients are welcome to join. There should be at least 1 call every day between 1 or more members of our team, and the product owner, to make sure the project runs smoothly.
Most of the day-to-day project communication will happen on the project’s Slack room. Project team members will CHICO (check-in and check-out) to let everyone on the project know their daily timings, including when they’ll be back online the next day.
Our process isn’t necessarily a rigid one, but it typically goes something like this, on a UX and prototyping focused project for a web-based app. Mobile is a little different, but this should give you a good idea of how things usually go down:
- Complete the Day 1 kickoff: identify and prioritise user stories and agree a workable scope for the project, or the sprint at hand. Make sure the client is clear on the focus here: to work towards a MVP as soon as possible, to allow us to solve the tricky problems sooner. We get more fine-grained, later on.
- Discuss and delve deeper into requirements if necessary, where these are complex and require more research.
- Sketch out a loose application content architecture and structure before prototyping.
- We begin prototyping. Typically using Middleman along with Riggings to allow rapid development. The first stage here is very blocky outlines of key pages and functionality, thinking at a high level. We scaffold the entire application as quickly as possible, throwing up placeholder pages and content. Clients provide feedback as we develop, using BugHerd commenting directly on the prototypes. Feedback is pulled into a Kanban taskboard and assigned to our team accordingly. A post-commit hook inside the git repo automatically marks these feature requests as complete once code is pushed to resolve them. Since all designers on the project are previewing the site with BugHerd running on their local environment too, this allows us to spot UX issues very quickly. Often, another member of the team will flag up a small issue they spot while working on some unrelated functionality, and it’ll be fixed very quickly.
- Once we’ve completed a first run-through, we iterate once again, digging deeper this time. Again, all changes are deployed to our staging server immediately and clients will frequently comment.
- We’ll hold daily calls with the client, where we review progress, talk the product owner through UX decisions, and discuss the business implications of key decisions. At this point, we’ve still not added any real visual design—we’re still working with unstyled Foundation or Bootstrap HTML/CSS/JS. We like to do this initially until we’ve covered the biggest design decisions, rather than prematurely getting too deep into UI design. It’s important to emphasise this to the client—they won’t see any of their own branding appearing until we’re well into the process. Not seeing distracting visuals too soon encourages them to focus on UX and functionality, not stylistic decisions.
- We’ll then aim to build out a pattern library for the application. This is again dependent on the time we have available.
- These general styles then get layered onto the app, fleshing out the design further and raising further questions to discuss with the client.
- We’ll repeat and iterate as far as is possible with the sprint time available!
Some technical notes
- Each time a commit is made, our Slack project room receives a push notification from the repository.
- Changes pushed to the repo are automatically deployed to the server. We usually use a quick Netlify site for both staging and production.
- The idea is that clients see work happening live and there is never any ‘big reveal’ at any part of the process.
- We use a git flow branching model to allow multiple designers to work on the project at once.
A frontend framework
We use either Zurb Foundation or Twitter Bootstrap as our framework of choice. Foundation is our typical choice for marketing projects, and Bootstrap for application UX projects, but it really depends on the project in question.
At the end of this design and prototyping stage, we’ll end up with a git repo containing all the ‘source’ files and templates for the app. This will include:
- CSS(3), in the form of Sass, for maintainability
- The Foundation or Bootstrap framework, on top of which custom styles will have been overlaid
- A Middleman app, which has the YAML data sources and similar content for the application, to keep things clean and DRY.
Depending on the project, we may also integrate with an existing application. We’re happy to work on the frontend—it’s common for us to work with clients on AngularJS projects, where we’ll be building out the frontend of the application, and they’ll work on building a backend and API to allow us to integrate with this.
Code ownership is a big deal for us. When a sprint ends, it’s crucial that everything we’ve done is owned by the client, and can be used by them going forwards. This means that whenever we use a third-party service (like GitHub, Heroku, etc), we set up the project in an account under the client’s name, not on one of our existing internal accounts.
When working on GitHub, we strongly push for the repository to be hosted on the client’s own GitHub account. not our own. By the time the sprint ends, the idea is to seamlessly transition the project across to the client’s own team to manage and maintain on a daily basis.
After the week’s invoice has been paid in full, all code produced in that week is considered to be owned by the client.