- Welcome
- What Design is. What it’s not.
- Design is wasteful. Embrace it.
- Process
- Collaboration
- Respect
- Sprints
- Remote Working
- Communication
- Tooling
- Discovery
- Design Process
- Testing
- Design Standards: Usability & Experience
- Design Standards: Execution
- Style Guides
- Contributing
This document, like this company, is a work in progress. We welcome changes, suggestions and improvements. Consider these guidelines the baseline for new products and services that we build together.
“If you’re not solving a problem, you’re not designing.”
– Kyle Steed
At Next, everyone involved in the creation process, designs. Whether you do that with code, words, sketches or software is irrelevant. If you’re making or shaping the way a product works, you’re designing.
“Design is a set of decisions about a product. It’s not an interface or an aesthetic, it’s not a brand or a color. Design is the actual decisions.”
– Rebekah Cox
Aesthetics are important, but they are not design. Design is solving a problem. And we solve problems with decisions about how software, processes and services can and should work. We do that in fluid and dynamic teams. We do it with respect and mutual deference. We do it inclusively. We do it pragmatically and professionally.
A brief is a quarry. A problem well defined is a rock hewn out of the quarry. The design process is everything that it takes to turn that rock into something of use.
Don’t polish the rock. No one wants or needs a rock. More of the rock is going to be discarded than used. Take rough strokes, be messy, choose quantity over quality. Rocks are forgiving.
As your design takes shape the time for being brutish will be over. There will be process and detail. There will be stakeholders. Every stroke will matter. A sculpted form is less forgiving.
Be wasteful in the beginning so you can be calculated in the end.
Embrace the fact that 90% of your work will lie on the workshop floor. But it will inform the 10% that matters.
“Inspiration exists, but it has to find you working.”
– Pablo Picasso
Our design process adapts to the unique requirements, deliverables technologies and contexts of the problem we are trying to solve.
One thing that can be said about every Next project is that we have a bias towards making. That means we focus on creating sketches, prototypes and working ideas as early as possible.
Discussing ideas in the context of a design, regardless of how polished, is the best way to facilitate discussion that move the project/process forward. Responding to discussion points by variating and iterating a design, the prototype becomes the documentation – a history timeline of decisions that have shaped the product.
Having said that, we do insist on some textual documentation, and whenever we do documentation we want it to be useful, because bad documentation is not only pointless, it’s a waste of time.
Because designing is solving problems we involve a broader spectrum of people in the design phase of our projects. Strategists, Developers and Clients contribute to the design of every experience we build. That means getting used to having people sharing opinions and ideas. It means learning how to hold subjective opinions lightly. It means learning how to choose what feedback to include and exclude. It means learning how to value what’s right over what’s nice. None of this is easy, but what comes out of it is better.
Collaboration requires respect. Whether this is your first job or your tenth, if you work here its because we respect you. Respectfully agree, respectfully disagree. Be passionate about your ideas, be passionately opposed to an idea. It’s fine. Just do it with respect. Always.
The Next studio runs on a 5 day sprint system which starts on Monday. This makes it easy to manage workflows and to plan who is working on what and when. We plan our workflows a week at a time.
- Your workload should be clear at the start of the sprint
- You should not get any new work allocated once the sprint has started
- Any work labeled as high priority should be done first, low priority last
- If you’re assigned too much / too little work, speak up – preferably sooner than later
Weeklies are one of the very few meetings we have where we review work done / not done in the previous sprint, and talk about the objectives for the next sprint. We really need all hands on deck at these.
- A Weekly marks the end of a sprint and beginning of the next sprint
- We typically have a weekly for each client or for a project if its big enough
- You’re only required in a weekly, if you’re working on that client/project in the sprint
- As soon as you’re no longer required in the Weekly, you can go
We want you to be able to work wherever you’re going to get work done. Next has had a remote working policy since day one. Which you can read about in depth here. But with much freedom comes some responsibility.
- Notice: Tell people in advance when you’re wanting to work remotely
- Communication: Be more communicative than you’d ordinarily be to make up for the fact that we can’t walk past your computer, bump into you at the watercooler or smell your cologne
- Going AFK: Tell us what you’re doing, tell people when you’re stepping away from the keyboard
- Share your work: when it’s work in progress, when it’s done, when it’s not working out
- Save your designs – often
Remote working is kind of a new thing for many people who join us, so we wrote a separate remote handbook which you can read about in depth.
Never. Ever. Go. Dark.
We run our entire business through Slack and GitHub. If you’re not available on Slack, you’re not in the office. If you’re not committing code or closing issues on GitHub, or uploading designs to InVision you’re not at work.
Basically Slack & GitHub or it didn’t happen.
Some people are less communicative than others. We get that. But if you want to work remotely you have to be a good communicator. Not just in our company. In any company.
You’re encouraged to use whatever you want to get your ideas out of your head and in front of people, but there are some tools that we either recommend or require you to use so that we can play nicely together and get shit done.
We use sketch because it’s amazing. It’s affordable, easy to use, extensible, low bearing on processing power, and it delivers amazing results.
Photoshop is still really useful for editing photos and working pixels. We use it too, probably less and less every year.
If you’re designing an interface, InVision helps you turn static designs into an interactive prototype. It’s a simple more effective way to present and share our designs, give feedback and manage feedback.
It’s important mentioning that almost everything that gets designed at next will become a Style guide before being implemented into a website or app. At Next we have our own boilerplate style guide that is adapted for each client and project. It’s central to our design workflow.
We use Google for all of our docs, spreadsheets, presentations and asset storage. We encourage you to have all your working files backed up by using Google Sync. Because shit happens.
Slack is the artery of our workflow. Our offices are generally quiet. Slack is never quiet. Everything happens there. We talk about work, we talk crap, we share work in progress we share stupid links. If you’re on Slack, you’re in the office.
If you’re not writing code, you’ll experience GitHub as a project management tool. You’ll get issues assigned to you, which you close when completed. This is covered more in Sprints.
We cannot create a solution to a problem we do not understand. We consider researching, immersion and creating documentation as the kickoff for the design process.
- Discover what the problem is for the business and for the user
- Discover what others have done to solve the problem
- Discover what we need to do
- Discover what success will look like
Discovery is not a deliverable. So our processes and documentation must be action oriented, helping to direct us towards making something useful – as soon as we possibly can.
We use a simple tool called an "Assumption Sheet” to facilitate a process for stakeholders and ourselves to share our assumptions about the business. We all have assumptions, whether stated or not. Declaring them at the beginning of the project helps to get perspective, set expectations and get on the same page.
Another tool which we usually workshop with the client is a sequence of stupid questions, which always sparks interesting discussions about core issues in the business.
Help us to understand emphatically with who we are designing for. Stereotype driven ’gutfeel’ user personas are worthless. Use Personas when you have research and real insights into your users.
Jobs to be done is a different approach to User Personas focused on understanding what job a user is trying to accomplish. They’re our preferred method.
User Journey Maps chart the flow of a user through a website and is particularly useful when the product is transactional, with complex interfaces and logic determining how a user experiences a product.
We’re not big on enforcing a rigid process on any and all problems, but if we take a step back and look at the work we’ve done to date our design process tends to follow a common pattern and set of priorities.
“Content precedes design. Design in the absence of content is not design, it’s decoration.”
– Jeffrey Zeldman
Design is giving shape and form to content. For that statement to be true, you need to consider content as being more than words and media. It’s the substance of the design.
When building websites with static content the core content copy, images and assets should be accessible from the start of the design process – this is, after all, the the stuff we are designing.
When building tools or designing a site for dynamic content the process is trickier. The content we work with here is more abstract. We look to the Information Architecture for patterns, atomising content into “types“ and identifying ways to design robust interfaces and patterns to cater for all the types of content we envisage users creating. It is still critical to consider the content first before designing.
Early in the design process we focus on getting a variety of ideas and approaches. Variation is about exploring different ideas. Start iterating too soon and you can go very far down the wrong path. Early in projects we will typically hold workshops, design studios, or have multiple people working on solving the same problems to get as many perspectives as possible.
- Sketches
- Conceptual Comps
- References
- Limited Prototypes
- Style Tiles
Once we’ve decided on an approach we begin focussing on iterating the design, crafting a single approach to move it forwards or backwards – with each iteration we’re trying to make a single design experience simpler, better, faster.
- Wiredframe Prototypes
- Responsive Prototypes
- Component Prototypes
- Production ready assets
We don’t often design in the browser, but we always decide in the browser. Before an interface goes into production it needs to be componentized, broken down into reusable, responsive building blocks and reassembled into patterns and templates. A design will change here too – there’s a lot of fine tuning and occasionally some root canal surgery that has to happen to design at this stage. Embrace it. We don’t make PSDs, we make websites.
“An interface is a place where two things meet: the human and the computer. The computer has functions it can perform. The human needs inputs and outputs to take advantage of those functions.”
– Ryan Singer
Integration is the last frontier of the design process. Integration can and will influence our designs. So we embrace it and use this time to make our design better.
Check yo’self before you wreck yo’self – there are some great tools to help you test your ideas, colours, typography, etc.
You shouldn’t design a website or interface without a clear KPI in mind. We regularly audit our clients websites looking at user flows in Google Analytics to assess how successful our designs are in achieving their intended purpose.
We’re busy researching this topic and are putting together an approach to conducting usability tests with users.
We’re proponents of the tenets of Universal Design, which we’ve adapted slightly for non-physical products and interfaces. Some of these principles are essential – some of them are north stars, seemingly unattainable but to be pursued at all costs.
The interface design prioritises the user’s experience and needs over the business issues. Where the users best interests conflict with the business requirements the design must favour the user.
The interface design is useful appealing to people with diverse abilities. The intentions of the design translate across a spectrum of browsers and viewports.
The design performs well. It loads quickly, it functions smoothly and aids the user in completing the task.
The design is easy to understand, regardless of the user’s experience, knowledge, language skills, or current concentration level.
The design communicates necessary information effectively to the user, across a broad spectrum of ambient conditions and user sensory abilities.
The design minimizes hazards and the adverse consequences of accidental or unintended actions.
The design can be used efficiently and comfortably and with a minimum of fatigue and friction.
Appropriate size and space is provided for approach, reach, manipulation, and use regardless of user’s size, posture, or mobility.
Designing for a multi device world means catering for screens of all sizes and kinds that are used in a number of contexts. It is more helpful to think of design in terms of screen sizes – and less helpful to think of design in terms of device type. For this reason we almost always design interfaces using a relative or a fluid grid system. Very few static design tools allow users to work this way, which is why we always decide in the browser. Even so, it is possible to accommodate this by designing using percentages of viewport width.
In a multi device world Typography is equally as challenging as page layout. When dealing with typography we have to not only contend with the weight, flow and fit of copy on different screen sizes; we also need to consider the reader’s position in relation to the screen. In the same we that we work with fluid layouts, we use relative typography sizes, measured in em’s.
Basic rule of thumb here: this is Africa – reduce your file sizes. Uncompressed images kill page load speeds and performance. We use Kraken to compress our images as far as we can without them looking shitty, and wherever possible load optimally sized responsive images and typically outsource video hosting to third parties like YouTube or Wistia.
“Animation can help to provide context. It helps brains understand how the information flows.”
– Pasquale D’Silva
We believe that the role of animation in interaction design is primarily one of visual communication, that is using movement and changing states of objects to convey a message to a user. Animation for animation’s sake can become confusing and interfere with performance across browsers and devices.
At Next we’re able to be flexible and adaptable because we work with design patterns. Patterns require restraint on the part of the designer. The closer we get towards production, the more important it becomes to audit your designs and normalise them – that means reducing the number of variants of a pattern. Use common values, common patterns – reuse design patterns as much as possible.
Performance is as critical to design as the pixels we push around onn our screens, perhaps even more. Don’t design your way into an 20 second page load; share your designs early and often with a broader team.
- Setting A Performance Budget
- Collection of Designing For Performance Resources
- Responsive Images
- Use SVG for icons, not images
- Kraken your images
At Next, the style guides we create are the manifestations of our design systems. They provide our clients with the scalability to support their business or product into the future on the Web. A style guide helps to maintain the brand design and code consistency of the website as it grows over time.
Web pages comprise of basic elements combined and laid out to create a user interface. The majority of websites that you browse have many common elements. These include color palettes, typography, navigation and buttons to name a few. We ensure that these elements remain consistent throughout a website by building a style guide. Our style guide contains all the individual parts of our design system. It also shows you how they get put together to create the templates which you see when you visit a website.
There are many approaches to creating style guides, but we’ve opted to stick to a boilerplate style guide which allows us to build working interfaces faster. Our Style Guide has evolved over time, and will continue to do so.
Elements are the basic building blocks consisting of headings, buttons, icons, etc. They also include more abstract things like color palettes, font stacks and grids.
Patterns are groups of elements that are combined to function together as a unit. Building patterns from elements encourages the creation of reusable interface markup.
Templates are built from elements and patterns which have been combined together. They provide context and are focused on structure as opposed to actual content.
If you’ve found this book helpful, awesome. If you think there are some additional things we should add to it, even better. We want joining next to be as seamless an experience as possible. To make a suggestion add an issue, or submit a pull request on GitHub. If that’s confusing, send a mail to [email protected]