Phase Three: Design

Contents:

Phase Summary

  • Branding & Identity
  • Visual Design
  • Application Design

Typical Outcomes

  • Living style guide built in HTML/CSS
    • Including: color palettes, typographic headline, paragraph samples, buttons styles, grids, form styles, etc.
  • Thumbnails and sketches
  • Branding/logo files in required formats
  • Design reviews and approvals
  • Low-fidelity prototype/grey box wireframe
  • High-fidelity prototype (IOS/Visual Design)

Note

Every designer has a process that works for him or her. You should find a process that works for you, but don’t be afraid to try new things especially when those things could make you a stronger designer.

Branding & Identity

Polishing or redefining a client’s brand and identity is about creating a visual language. Once the brand attributes have been defined and the company goals clarified, it’s time to experiment with visual metaphors that reinforce the brand.

Go Abstract

Mini-exercises and multiple iterations keep the design loose and fluid, letting us play with and refine our ideas — including the things that feel clunky or unrelatable at first.

Conceptualize

Once we’ve got a direction, we develop some workable concepts. Then we mix our wordmarks, icons, and monograms together and distill the best ones. Filter and repeat. Keep the team involved early on and get feedback from them throughout the process. If the team is feeling good about our concepts, we show some low-fidelity sketches or thumbnails to the client. The designer has the client pick a direction based on the types of sketches that feel right so we can continue iterating.

Execute

At this point, most of the heavy lifting is done. It’s time to define some important details:

  • Typography
  • Color palettes
  • Icons/patterns/imagery
  • Any needed print materials
  • Other online materials

Illustrate how the design (logo/wordmark) will look in different environments like on t-shirts, stationery, vehicles, etc. Be sure to test how the design renders with different screen resolutions.

Allow time to get internal approval from the team for your best one or two concepts. A good critique means focusing on what’s working and what’s not and why. Refine the designs if needed.

The team schedules a call and the PM and designer meet with the client to review and walk them through the designs so they don’t misinterpret the recommendation. Also post the design with a clear rationale in Basecamp for the client to access. Use clear communication with clients, referring back to the project goals outlined in the kickoff meeting. Ask clients to provide feedback based on what is and what’s not working with the design. Gently guide them away from providing solutions for what’s not working; if they’ll clearly relay the issue, we’ll provide the solution. This improves the ability to act on the input and allows the client to respond pragmatically. Record any additional requests by the client so the team can track them and budget for them, if needed.

Note

Refer to the signed agreement regarding how many rounds of design revisions were approved. If additional rounds are requested by the client, have the team provide an estimate and receive approval before proceeding. This should also be noted in the Monday client update as “New Requests.”

WAIT! SIGN-OFF REQUIRED!

When the client has approved the design in writing, develop the branding guidelines and a style guide for the client. Create a folder and put design files in there. They’ll get uploaded to Basecamp before the end of the project for the client’s use.

Visual Design

To dive into visual design, make sure the team has completed these things:

  • Research on client, their site or app, and competitors
  • Defined the problems/tasks that need TLC
  • Client assets, branding guidelines, etc. are available
  • Content is defined, organized, written/edited (AKA no major changes will affect page layouts or hierarchies)
  • Rough site map

UX Design

Start by roughly sketching out major pages and layouts. Work closely with our content strategist to lay out a low-fidelity prototype referencing actual or virtually similar content. That way, we’re not just making a bunch of grey lines symbolizing ‘content’–we’re actually building around the expected amount, type, and organization of content, without actually getting distracted by it. Another way to reference this type of design is to create a “live” grey box wireframe that shows the depth of functionality and lets us flesh out the major components of the site or app without boxing us into defined visuals. We’re using Travis Gertz’s Live Wires prototyping method which basically allows us to build a live HMTL/CSS frame that we use throughout the project. It allows us to apply our design straight to the code without throwing anything away.

Note

Here are some of the basic differences between wireframes and prototypes:

  • Traditional Wireframes allow you to set up your page layouts and hierarchies, but you need to create copies for each page type and links, buttons, etc. are inactive. Basically you’re creating an ‘image of your site or app’. Clients can’t see how the functionality works together or how big the entire site or app really is.
  • Low-fidelity prototypes allow you to navigate through the entire app or site to see all the components without seeing a defined look and feel. Makes it easier for clients to focus on the moving parts instead of what they might look like.
  • High-fidelity prototypes is like your front-facing interface without a database or CMS hooked in (too detailed to show a client until everyone determines an early prototype direction). Once the look and feel and low-fidelity prototypes are approved, styling and the reveal of actual content in the design turns this into a high-fidelity version which is still flexible but ready for design approval before development.

We let our content, sitemaps, and layouts stay fluid during prototyping to prevent any design decisions from being set in stone. We iterate and stay experimental by alternating between in-browser designing and sketching with good old-fashioned pens. The trick is to stay as low-fidelity as possible, using grey lines in place of actual text to keep the client focused on the overall hierarchy and flow of information rather than the look and feel at this point. We also write our prototype so that we can use the same code throughout the project.

Naming Conventions

We’re working to standardize our naming conventions in our HTML/CSS code so that it will translate if/when a mobile site needs to evolve (often with a wrapper like Phone Gap or other technology that makes a site into a non-native app). We may be able to save time by having consistencies in the way we refer to elements, preventing the naming conventions for mobile and sites from clashing when translating from CSS to Cocoa.

Review Internally

Present a low-fidelity prototype to the team. Be sure to get the feedback of any UXers, developers and content strategist to make sure everyone is aligned with core components and the scope is the same. Bring another designer in for additional feedback. Give the team enough time to provide feedback internally before showing anything to the client.

Show it Off

Now the designer and the project manager present the prototype to the client in person or over a screen share. Walk clients through the project, explain the purpose of the prototype and feedback we’re looking for so they can share the right information with their organization and feel comfortable navigating the site or app. Refer to the signed agreement regarding how many rounds of design revisions were approved. If additional rounds are requested by the client, have the team provide an estimate and get approval before proceeding. This should also be noted in the Monday client update as “New Requests.”

Note

Cross-reference the documents created in the definition stage with the client while presenting the designs. Things like the sitemap, components list, and content docs will give them a clearer picture of how things fit together. Minimal changes to the site design are fine, but anything that results in changes to the sitemap, page layout, or page hierarchy needs to be noted for estimating and the requests added to the Monday client update as “New Requests.”

Ask clients to provide written feedback in Basecamp based on what’s working for and against the design. Gently guide them away from providing solutions for what’s not working; if they clearly relay the issue, we’ll provide the solution.

WAIT! SIGN-OFF REQUIRED!

Once the team gets written approval, you can start developing the style guide and cementing the look and feel.

UI Design

The first step in UI design is for us to gather any branding guidelines & visual assets from the client and make an inventory of constraints to guide our design.

Typography

Next, we set base typographic decisions in the browser based on client guidelines. Typecast is a fantastic tool for making and comparing typographic decisions in the browser. It’s a good idea to begin with the idea of the perfect paragraph...

  • Set the font
  • Size
  • Line-height
  • Maximum line length
  • Color

We can use these as the basis for all other typographic and layout decisions. This will make sure we create a tight, typographically sound design where elements are tied to each other re: size and proportion. Here’s a quick reference to basic typography.

Grid

Next, we design a grid that will work across all viewport sizes and provide a robust framework for our content. Decide on a modular scale to reference to assist with determining proportional sizes for headlines, grid/gutter units, layout elements, spacing, etc.

Note

Tim Brown’s video on his Modular Scale generator is an invaluable tool for creating custom scales outside of the traditional 8,10,12,14,18,21,24,48 scale. 24 Ways presents another article on scales.

Design Components & Style Guide

Instead of thinking in page templates or sections, instead we begin designing individual components for the app or site in HTML & CSS using an HTML style guide or something like Brad Frost’s PatternLab. We document small things like type styles, form fields, buttons, links, images, then move up to combinations of elements like forms, callouts, tables, and repeating content modules.

A detailed style guide is a great preliminary design deliverable we present to our clients. It lets them see how we want to move forward with the look and feel, and it clarifies how elements work with each other before cementing anything. It also gives clients a tool they can reference in the future when they want to update their site or app. The best thing is that it lets them provide early design feedback so we don’t have to back up when we apply these attributes to the prototype.

Brad Frost’s Atomic Web Design is a great reference for this type of approach.

Apply the Design

After the style guide is approved by the client, we apply the CSS written for the style guide to the Live Wires prototype to begin designing in-browser. Most of our design decisions are laid out and we spend the rest of our time fine-tuning our design and fleshing out important details, page by page.

Flow the Content

Our content strategist applies the text in basic HTML to the high-fidelity prototype while our designer applies the style guide attributes to the rest of the design. A content first approach means that we’re not ‘selling’ content development. It’s simply part of the design process. When clients provide the content themselves, we work with an experienced copywriter supplied by the client to make sure we’re aligned on our content and design goals. Lorem ipsum is a fairweather friend and will not inform how much content will actually need to go on the pages. Avoid it, except maybe in places where microcopy show us when additional copy needs to be made.

Review Internally

Present a low-fidelity prototype to the team. Be sure to get the feedback of any UXers, developers and content strategist to make sure everyone is aligned with core components and the scope is the same. Give them enough time to provide feedback internally before showing anything to the client.

Note

We usually design out a few core pages with the anticipated look and feel and get ready to show it off internally and then to the client in our first round of design. This prevents us from going too far in a particular design direction and getting feedback that forces us to change direction, eating up our budget. It also gives us a chance to review our available budget early on and re-estimate if necessary.

It’s also a good idea, no, a GREAT one for designers to review their code before any formal QA process. Be sure to cover this time when estimating for the scope.

Show It Off

Round One: It’s easier to do a live walkthrough of the design with clients, then the project manager and designer follow up with screenshots of specific pages at different screen sizes (we usually stick to desktop and mobile for round one) and a written design rationale afterwards. This removes the environmental inconsistencies of the client viewing with different browser types, versions, and seeing bugs since we don’t do browser testing on a moving design target (so many visual elements are apt to change). Make sure to explain the reason for the screenshots, include our Project Manager so he or she can guide the walkthrough and the designer is there to answer more technical or creative questions.

Ask clients to provide feedback based on what is and what’s not working with the design. Gently guide them away from providing solutions for what’s not working; if they’ll clearly relay the issue, we’ll provide the solution. This improves the ability to act on the input and allows the client to respond pragmatically. Record any additional requests by the client so the team can track them and budget for them, if needed. Clients provide written feedback in Basecamp so we can either re-estimate new requests or adjust our design direction and resubmit.

Round Two: Now that we’ve adjusted our designs and made sure we have enough time estimated for round two, we flesh out the rest of the pages and send our final round of designs in screenshot form to the client and get written feedback and approval in Basecamp. Additional revisions can be estimated when the client would like to see more rounds of changes.

We try to work closely with the content strategist, user experience team, and developer to support the content, user flow, and functionality of our designs.

Note

Refer to the signed agreement regarding how many rounds of design revisions were approved. If additional rounds are requested by the client, have the team provide an estimate and receive approval before proceeding. This should also be noted in the Monday client update as “New Requests.”

Once we receive written approval, we tidy up the front-end code, apply any last tweaks, and package up our files for development. We schedule an internal development meeting to discuss database, CMS needs, as well as any other quirks or areas that need extra love and attention. We’re now ready for development.

Application Design

App design is its own beast. If the team decides that an app needs to be created (mobile/tablet/desktop, native or not), we work in predetermined sprints to complete the work. The design and development phase are often blurry since designers and developers are working in tandem throughout the process. When in doubt about how to move forward, we talk to our teammates.

UX Design

First, the designer or UXer outlines a user flow. This can be shared in a few different forms:

  • Thumbnail sketches of screens and where each call to action leads us.
  • Photoshop doc that highlights this user flow in more detail.

OR

  • The biggest time saver: Live Wires ‘grey box wireframe’. Interactions and user flow are retained and the code can be saved and the design can be applied on top. Nothing is wasted.

Then the designer works rapidly with the team to outline a high fidelity prototype that will guide development work. App design differs in that the prototype can be created before the visual design since we create and apply many of the design elements while our developers complete vertically sliced sprints. Once each ‘slice’ of the prototype has been completed and approved internally, the team determines which slices the client will see. Early feedback is a must since it helps us avoid scope creep.

The team decides how best to present the design to the client and reinforces the initial business and project goals before showing each iteration. Repeating the clients words back to them helps us make sure that we’re interpreting their feedback correctly. Again, we ask them to focus on what’s working and what’s not working rather than what they like or dislike. This keeps the feedback objective and allows us to maintain our role as the experts creating their product while still being responsive to any changes the project needs to be on target.

Be sure to have the client write down ALL design feedback each time, so we can determine any additional requests, functionality, or changes in direction before they slip into the design without re-estimation. Re-estimate any changes to scope immediately.

Note

Vertical slices: an approach where an individual component of an app is completed during a sprint before moving onto another component (e.g. sign-in screens are developed, then we move onto dashboards).

  • When developing assets, make sure to accommodate retina display first and then scale down the display to accommodate lower resolutions. Don’t forget the mobile assets. We’ll need to create high- and low-resolution versions for each. Get started early and work closely with the iOS developer to make sure the designs align with development goals and timelines.
  • Make sure the team is clear about gestures and interactions. Since these differ from mobile and tablet to desktop, we need to have clarity and approval for how we’ll interact with the app. Standards FTW!

UI Design

Now it’s time to establish the look and feel. The designer works with the team to create a striking UI. Again, there are several ways to do this, but we’re moving towards designing in browser since this is the most efficient, cleanest, least wasteful approach.

Style Guide

We start with a style guide.

  • The designer creates components in Photoshop so the developer can cut them (things like buttons, UI elements).

OR

  • The designer designs in browser to create a responsive HTML/CSS file that can be dropped on top of the high-fidelity prototype.

The designer shares the style guide or component document internally and brings in another designer for feedback before arranging a meeting with the PM to share with the client. Try to keep the visual design revisions to two–even though we’re sprinting in development, we need to keep the visual design approval process tight. This prevents scope creep during development after we apply the design. Get written sign off from the client in Basecamp. We’re now free to create the rest of the UI elements.

Design Remaining UI Elements

After getting approval for the style guide/components document, the designer codes out or designs the remaining UI elements so that the developers can plunk the design over top of the prototype. Once this has been done, it’s a good idea for the entire team to sync up and make sure there are no code conflicts or UI elements that conflict with the interactions or code. Once the design has been applied and the whole team is feeling good about it, show the client a walkthrough of the design and get final approval. Again, keep rounds of revision for design to two. Remember, we can differentiate between the look and feel and the interaction so if the client asks for any changes that aren’t related to the aesthetics, add these requests in as scope changes or ongoing sprints.

Note

It’s a good idea, no, a GREAT one for designers to review their code before any formal QA process. When in doubt, use our internal QA checklist to guide your work. Be sure to cover this time when estimating for the scope.

Reasses the timeline with the client regularly so everyone is clear on the expected delivery. It’s also a good idea for the PM to connect with the content strategist, developer, and client to begin to finalize things like required app store accounts, billing, content and keyword writing well before the app launches.

Get Everyone on Board

Keeping all key players involved from the outset is important. Rapid iterations with the client are valuable, but the feedback from everyone on the team in-between ensures that there will be no scope creep, miscommunications, or info gaps. It’s vital to do user and ongoing internal testing on the proposed app or site to make sure things work the way everyone anticipates.

Keep it Fluid

Approvals and sign-offs for apps during this phase are obviously more fluid than they are with traditional sites. As long as there is clarity about how ongoing iterations affect the scope and budget, the team is free to create as many as the project needs to nail it down within the scope. That said, a clear schedule and related estimates for releases and updates should be implemented as soon as possible to avoid scope creep. It’s also a good idea to schedule regular product reviews with the team to manage goals and expectations.

WAIT! SIGN-OFF REQUIRED!

Note

Sign-off is especially important for app development! Making changes to a working prototype once it’s been finalized creates scope creep and can keep the team designing and developing for the same release for a long time, not to mention causing the client’s budget to balloon, leaving both the team and the client frustrated. Schedule adjustments in later releases to keep things tight.

Once the team has approved the UI design/development and they get written approval from the client, it’s time for another round of testing and a final QA. Remember, development is often running in vertical slices at the same time, so lots of team planning is necessary to keep these releases in sync.