Designing a large responsive website – The Trey Songz responsive redesign process

Most of what has been written about responsive web design has been from the perspective of a web developer, or a single person designing and building an entire small site. I’m going to break down a large responsive project from the perspective of a designer working as part of a larger team. I will outline my design process, how our team made decisions, and the tools we used to get from idea to completed designs.

This project was a redesign of TreySongz.com, one of the most trafficked websites for Atlantic Records and the first responsive website for Warner Music Group. The site was built by an external developer, another good reason to keep the conversation design focused. I hope showing a real large scale project helps take some of the fear out of responsive design while representing the challenges of responsive design in a realistic manner.

To view the finished designs check out the full project on Behance.

trey Songz responsive website


Trey Songz was the first Atlantic Records artist to get a separate mobile website nearly 18 months ago. Mobile traffic had grown quickly since then and we needed a new mobile experience with the same features as our desktop website. We already knew maintaining a separate mobile website wasn’t a scalable solution.

Our goals:

1. All content from the desktop site should be available to every user regardless of device. While there should be different ways to navigate content on mobile, we didn’t want anything to be inaccessible just because you were on a phone.

2. To think mobile first, but realize desktop is and would continue to be the majority of our traffic. The average lifecycle of a music website is less than a year – realistically not enough time for mobile to catch up. The desktop experience couldn’t suffer.

3. To create the best possible interactions for each device. For example, long scrolling areas on the desktop would become horizontal swipe enabled sliders on mobile devices. We also designed the footer navigation to show additional content on click thereby removing the need to load separate landing pages on mobile devices.

trey iphone


The first step I take with any website is a content outline. This can be anything from a spreadsheet breaking down every element on every page of the site, to simple annotated wireframes. For TreySongz.com, I worked with digital marketer Michelle Cranford to dive into who Trey is as an artist and where he was in his career. We made a decision to focus on his new music and videos (the site is being launched just before his record) as well as highly visual content like photos, minimizing the focus on his tour. Because this was the fourth redesign of this site I had been involved with, we kept the content outline brief and jumped right into sketches.


I always start wireframes with paper and a pencil. From the beginning Pete Jelliffe (WMG UX Manager) and I sketched mobile and desktop wireframes side by side. We didn’t take a desktop or mobile first approach but treated both elements as equals – parts of a single whole. We compared mobile and desktop sketches to anticipate the reflow of content and marked any elements that differed between desktop and mobile in a spreadsheet.

I made the decision to design for the tablet in the browser. In most instances it is more efficient to work directly with a developer to create a tablet version of a site rather than wireframing each page. I only created tablet wireframes for the one or two pages that had significant issues scaling between mobile and desktop.

My next step was to create high fidelity wireframes for each page of the site, desktop and mobile. This step gave our dev team enough information to start prototyping the grid, the new activity feed, and new music pages while we completed visual design.

Wireframes were done in Adobe Illustrator which allowed me to move seamlessly from the UI phase to Visual Design.

Visual Design

The ultimate responsive design tool doesn’t exist. In the future I imagine a tool that allows you to design with a gui, is hooked into a fluid grid and outputs a package of html/css and optimized images. Until this magical day, Adobe Illustrator is my tool of choice.

The benefits on using Illustrator for responsive design:

1. Illustrator has symbols – this allows for reuse of elements throughout a design and the ability to edit elements in one location. Symbols also make collecting assets for sprite creation easy.

2. Illustrator has art-boards – this allows designers to have multiple canvas sizes side-by-side and to view different screen sizes in a single document.

3. Illustrator has text/paragraph styles – a shared feature with Photoshop, but styles in Illustrator can be exported to css using the HTML5 pack from Adobe.

4. Illustrator is vector based – you can easily create assets that can be made into SVG graphics or webfonts.

5. Illustrator can output to PSD – deliver to developers using a file format they are familiar with (and often request). As long as you break apart your symbols before exporting, you should be able to migrate all of your layers to Photoshop with ease.


Another indispensable tool for mobile design is Liveview. Liveview broadcasts a region of your Mac screen to an iOS device so you can view your design changes on a mobile screen in realtime. Necessary for fine tuning spacing, contrast and font sizes on a real device.


For development, every page was exported as a separate PSD from Illustrator, and SVG files were created for a few vector elements.

These files were accompanied by spec sheets created using Specctr, an amazing Fireworks plugin. Specctr allowed me to markup documents with just a few clicks and helped speed up the development process while increasing consistency across pages.


For Trey’s site we completely redesigned the functionality of his music pages. We wanted fans to be able to listen to all of the songs on an album, look at lyrics, comment on songs, and see the official video for a song all on a single page. Since this was a drastic change for us and we inserted a prototyping step here before design. Once we had worked with developers to polish these new interactions, I returned to design and skinned the page in Illustrator.


Invision App

During the design phase I used Invision to create clickable prototypes and test new mobile interactions. When we weren’t sure about the right design for a page, we would create a mobile prototype and put it in a users hand. A great way to test without wasting development resources.


Comps were approved from Invision and were always sent as a set. Part of responsive design for the foreseeable future is education, and we wanted to make sure the client always saw desktop and mobile as one object. Everything was shown on screen with the exception of the last internal review. Before sending designs to the development team all pages were printed and checked for consistency. To me, printing and marking up pages is still the best way to scrub a large scale site for inconsistencies.

After prototypes were complete, and designs had been delivered, we began reviews of the live site. At this point we made the rest of our changes in code, unless completely new assets were needed.

To mark-up changes and send them to the development team we used two different pieces of screen capture software:

Scroll Capture and Snagit

On touch devices we used Scroll Capture to capture full page screenshots on iPhone and iPads. We moved these mobile screenshots, along with our desktop screenshots, into Snagit where we could mark them up and create links for developers to review. These links were stored in Google docs so we could track changes in one master list.


I hope this was a helpful overview of a large scale responsive project from the perspective of a designer. While developers definitely have a lot of issues to resolve in responsive design, I feel like the design process has to evolve as well. Mobile and desktop need to be treated as parts of a whole. We need a better responsive design tool. We need to plan on how our sites will scale to different devices, even if we can’t always design for every potential configuration.

I want to thank my colleagues who helped work on this project – UX designer Pete Jelliffe, Project Managers Eva Nautiyal and Jeremy Kutner, Visual Designer Tonianne Tartaro, Digital Marketer Michele Cranford and the entire WEA development team.

This process was a learning experience for me, acting just as the designer and not building the site myself. How do you think we could have done better? I’d love to hear your thoughts and suggestions in the comments below.


Posted on: 11/06/2012


up arrow