I use pages for different "sections" of the site. One page for signup flow, another for login, another for account settings, etc. I like to have the first artboard of each page be a low-fidelity grid/layout/baseline of the entire site or even the initial wireframe(s) of that section.

However, as mentioned here and around, while Sketch can keep the file size for a complex document incredibly small (see: http://bit.ly/10LXGRH, note the file sizes), it can start to hang and bog down when too many large bitmaps are involved and especially if they're repeated. This is my experience.

Whenever I notice a performance hit, I take that section and make a new Sketch doc and paste it right in. You can go pretty far before having to do this.

• project-ui.sketch
• project-ui__some-heavy-section-that-i-isolated.sketch
• project-ui__another-huge-section-that's-maybe-bitmap-heavy.sketch

As for responsiveness - I usually put a mobile-sized artboard(s) next to (or above) it's desktop-sized counterpart.

I do separate documents for things like landing pages vs webapp view (logged in), separate art boards for each screen, and separate pages for each device.

Its always better to split them up into smaller chunks, just like how you would do with any features. Running a huge e-commerce website, it's tempting to put all the UI in one sketch file, seeing they made it so easy to manage. It's not the best method however, because it's harder to maintain in the long run.

Largely, this will come down to your own workflow and requirement. Are you doing design only or will you be responsible for building the front end as well?

I found the best method to manage this is start with a master template - style guide. Then duplicate them into smaller projects when you need them, e.g. check out flow, search, accounts. That way, its easier to manage and do multiple iteration of the same project.

One file for the whole UI.

I then create multiple pages for the different sections of the site. I always try to avoid bitmaps, use only vector.

First page will be components, then symbols, then all the sections of the ui separated by their own pages.

Components as all the elements. This is the visual style-guide. Symbols include all ... symbols, well everything that's being reused all over the interface.

Our latest project is a 65mb file and it's very fast. Sketch 3 did an immense job with speed with the new version.

We're starting a very big UI responsive app for a large bank in Europe soon, probably over 300 pages with options, etc. The initial version was made under Photoshop, which made it really hard to maintain and files became too heavy. It took time, but we managed to made them understand Sketch was going to be the best option for the redesign.

Their developers are under Windows, so we've been testing Avocode and looks very promising. There are still many bugs with big documents (that might cause file segregation), but we'll still try to put everything within one file. It's better for consistency.

Voilà.

I'm designing a giant tool right now and I find that a new Sketch file for each section of the tool is best. For example - a section for analytics, a section for a signup flow, a section for an overview.

Within each of those files my pages are as follows:

• Styles (all symbols, type style, and graphic styles in an easily editable place)
• Scratch (where messy elements get built and ideas go to die)
• Round 1/Round 2/Round 3 (bulk of work goes here in in a UX flow type of format with multiple artboards)
• To Share (a clean place to copy paste whatever I'm sharing from the round folder for a meeting, jam session, etc.)

Still hammering out my structure but this is where I'm at now. In my experience, trying to have all portions of an app in Sketch leads to slow response times, crashing, and bugs.

I set mine up almost exactly how you're explaining. I go through and define a bunch of custom things in the symbols page per project and save it as a template to start from. After I pick out type, design or find icons and establish colors Is et everything I can up as styles and start there.

but yeah I'm building out a large scale ecommerce thing right now and doing more or less the same thing.

It heavily depends on your machine but in my experience Sketch can't handle large documents very well.

I know I'm not answering the question but I'm feeling compelled to ask: why would you design a responsive website with a non-responsive tool in a non-responsive medium? Why not designing directly in the browser?

Thanks everyone for your real world experiences and workflows with Sketch 3, this was very helpful.

I'm in the process of redesigning a huge piece of software that, while not responsive, presents a lot of the similar challenges you're facing. For me, a methodology like Brad Frost's atomic design is priceless.

Given that I've already sketched out wireframes on paper or a more coarse tool like Omnigraffle, I split my Sketch file into separate pages, one each for 'patterns', 'templates' and 'pages'.

The 'pages' are where I rough out the visuals of the entire screens - how the header, footer and different layouts all play together. I then abstract this out into templates with a separate artboard for each. As I build these, I abstract out the patterns into the constituent atoms, molecules and organisms that Brad describes in the Patterns page with an dartboard for each type.

By starting holistically soon the patterns begin to build the templates and you find you are designing fewer templates/pages - I actually have moved back to Omnigraffle for them as I can churn out wireframes much quicker there, while everyone knows what each control or pattern should look like.

For me its about getting just enough into Sketch to inform the design so it can be built as soon as possible - my goal is for the HTML to be the canonical design, with only unknown stuff being done in Sketch - don't worry about your design files getting out of date, just throw them away and start again with the new features or pages.

Be careful of putting all your eggs (screens) in one basket (file). If that file gets corrupted somehow, then there goes your entire site. Idk if its paranoid of me but I err on the side of caution when it comes to something like this.

I've just started designing for a big web app and my process is very similar to the ones listed here. Different sketch files for different sections of the site - landing, settings, etc. Pages for sub sections, diff versions of subsections like v1, v2, etc., playground page for testing new ideas for that section. And finally, artboards for different screen sizes.

Sketch is alright for large documents if they are absent of images. If not you could get yourself in trouble with incredible load times. I haven't used sketch in a few months otherwise I'd tell you what my process is/was. I've been using illustrator as of late as it handles everything with a lot of ease even with nuisances. I typically isolate each file with a section of the website or a vertical part of the navigation. Within that file are artboards of different pages for that vertical portion of the website/app.

Just find something that makes sense to you, your team, and if someone were to come on in the middle of the project they could understand the structure.