A Modern Design Process

…Coming from a developer

How many of you like revisions?

Why do we offer revisions?

  • “The client has to sign off on something!”
  • “The client asked for them.”
  • “How else do you get feedback on a design?”

Answer is historical; client conditioned to expect them

You’ve always offered them.

Also involves typical workflow/process

Sales

Starts with sales:

Client says they need a website.

That’ll be $8250

You’re super stoked:

Big client

Good budget

Paid for your lunch

Get their name, logo, and email and they say, “Sweet, see you in two weeks!”

Boot up Photoshop

Start designing.
Create the next big thing. It’s glorious.

Email the client an export of the PSD.

“Here’s what your website will look like.”

“Let me know what you think!”

“ It’s a good start, but it needs some minor changes.”

“It doesn’t pop enough.”

“Can you make that green greener?”

You’re frustrated

Make changes in PS

“Here’s what your website will look like.”

Great! What will it look like on my iPhone?

Oh, like this!

What about my iPad?
Here you go!

Will it look good on my boss’s Blackberry? What about the Surface? I think I might get a Galaxy Tab. Retina screens!

This sucks!

You get the point.

This sucks!

The Big Problem

Expectations

(You haven’t set any)

What this leads to

  • It’s their job to manage expectations
  • Direct the project
  • Critique the design

The client:

Has to rely on previous experience

It’s their responsibility to ensure the success of the project

This is our fault! We condition them to do this.

What is your job title?

  • John the Web Designer?
  • John the clickity-click-mouse-clicker-person?

You determine which.

Every time you start a new project.

Tell your clients

  • What they will see from you, and when
  • The relationship between the end product and the deliverables
  • What kind of feedback is helpful; what kind is not
  • Who calls the shots

Part of your job description is defining the details of a project.

Feedback makes you want to tear your eyeballs out.

Lack of appropriate expectations

A process and set of tools that may not be best fit for the job.

What does a better design process look like?

Meetings

Starts with meetings.

Yes, meetings.

More generally:
communication.

Communication not only helps you design w/ data, it shows:

You know what you’re doing

You can be trusted with success

Gotta do a little handholding

A ton of conversation is way more effective than a handful of page designs.

Dan Mall

Conversation is cheap and not as hard as redesigning

(once you’re used to it)

Meetings are money left on the table.

Bill for these—they’re necessary

Discovery Meeting

  • What is your elevator pitch?
  • How do you make money?
  • What made you decide you need this project?
  • What functional pieces do you envision the site having?

Can even happen pre-sales.

Particularly helpful for atypical client/project

You may not comfortable quoting w/o discovery

Have everyone involved and have buy-in

A lack of buy-in will show throughout the project when devs/designers just do it because they don’t care about the biz’s success.

Expectations Meeting

  • What involvement are you expecting the client to have?
  • What deliverables are you promising, and when?
  • What feedback are you looking for?

Little? A lot? None? What does this look like?

One PSD? Five? Wireframes? Timeframes?

Preference/style? Or objective goal-based feedback?

Still doing handholding.

Business Goals Meeting

  • What are their general business goals?
  • What makes the project a success to them?

Besides making money.

Market reach

Number of downloads

Specific traffic stats

Specific sales figures

Target Market/User Goals Meeting

  • Who is their TM?
  • What will a visitor gain from the site?
  • How can the site preemptively offer to meet a visitor’s needs?
  • Design a persona

Easiest when client is in product biz.

Every biz has some type of target market.

Website shouldn’t ask “how can I help you?”

Design around the answers to that question.

Persona for recent client

Visual/Content Hierarchy Meeting

  • Determine priority of content and elements
  • Adhere to goals/purpose/persona

Defining/obtaining a sitemap

Waterfall of content based on importance

Napkin Sketching

Napkin sketching – internal “un”-deliverable

Design spikes; may not even end up anywhere.
Do something you think would look and work well, w/o constraints or preconceptions

Deliverables:
Information Architecture Prototype

  • Don’t design before you know content.
  • Don’t define content before you design.
  • Feedback: Does this IA prototype align with the business goals and content hierarchy we discussed?

Don’t design before you know content; don’t define content before you design.

Know what the content is made up of.

Is this an informational site?

E-commerce? News?

Maybe you’re defining these at this time.

Don’t define style of content-just placement

UXPin

Responsive, interactive prototyping tool—in the browser.

Online, no emailing files back and forth with 18 different names that you’re never sure which is current

Let’s you define breakpoints and prototype the content around those.

Library of pre-existing tools

- Bootstrap, Foundation

Make this as bare-bones as possible. It’s for IA, not style

UXPin

  • Version Controlled(!)
  • Backed up daily
  • Upload-able offline notepads(!)

More cool features:

Let’s you define actions-hover states, clicks, etc.

Give people the link, it will be responsive!

Built with a large library of pre-made tools – Bootstrap/Foundation grids and systems, button styles, form styles, etc.

Deliverables:
Color & Typography Palette

Make this in the browser! Write it in Sass!

Typecast lets you just get in the browser and see what fonts look like, on all screen resolutions.

Deliverables:
Pattern Library

  • http://patternlab.io/
  • Design/build modular components for use throughout the site.
  • Designed in the browser
  • http://demo.patternlab.io/

Opposite of many design processes; we often design from the page down (this is bad, bloats CSS, and is not future-friendly)

Encourages modular components for use throughout the site.

Designed in the browser

Has animation, hover states, and combinations that need to respond to their environment.

(Optional) Deliverable:
Design Skin
via Photoshop

  • WYSINWYG
  • Forces you into design silos—iPhone view, iPad view
  • Bloats as design increases in complexity

“What You See Is Never What You Get”

Fonts, line heights, gradients, colors, can all look differently in the browser.

Predefined screen widths

Multiple PSDs for diff. screen widths

Copying and pasting to duplicate elements

Requires changes in multiple places

(Optional) Deliverable:
Design Skin
via Sketch

Parameters of app and web design in mind

Doesn’t enable/encourage you to design in browser-incompatible ways

Reusable elements & layer styles

Create symbols for frequently used/repeating elements.

Change once, change everywhere.

Ditto Layer Styles and Text Styles; are akin to CSS—styles that apply throughout your document.

Change them in one place, they change everywhere

Grid systems

Exportable, scaleable assets

Generate 1x, 2x, PNG, SVG, all in one step

Delivery

Don’t pull a drive-by email delivery of the design, shouting “Let me know what you think” over your shoulder as you speed away.

In fact, NEVER ask, “what do you think”.

Delivery

  • NEVER SAY “What do you think?”
  • Always present via a meeting
  • Don’t sell the house on the quality of its drywall; sell the value
  • Be open to correction

Do not send a deliverable to the client and ask for their feedback.

Have a meeting where you present the purpose, thought, data behind each component of the deliverable.

No real-estate tours. Your client knows what their logo looks like; don’t point to it and say, “here’s your logo”

“Sell” how the current deliverable meets their business goals (it does, right?).

Walk through the site as if you’re in the persona you designed: Are your needs met?

Encourage the client to give feedback based on their area of expertise (their business) and leave the rest up to you.

Be open to being wrong.

It’s ok if you misunderstood or misinterpreted a business goal and how you translated that to design. Let the client know that it is helpful to know this as soon as it is recognized.

The goal of a presentation is to show your client what you believe will meet their business goals.

Feedback

  • Know who’s involved
  • Hone ^ down as project progresses
  • Focus on:
    • Tone
    • Voice
  • Ignore:
    • Subjective opinion (like, dislike)
    • Can’t be matched to goal
    • Design dictation
    • A comp the client made

It sucks to get to the end of the project and be told that the CEO has some additional feedback/changes

Whittle the number of inputs down; often people just want to throw something in anyway.

Do this up front and be clear that this needs to happen and be done with.

Focus on:

Tone – does it feel like your company?

Voice – does the language match the intended brand perception?

Ignore:

Require feedback to have reasoning behind it (in a non-confrontational way)

Don’t accept feedback like, “the logo/header should be bigger”. The green should be greener. Font more bold. NO.

Prohibit the client from making their own “version” of your design, in your contract.

Keep the goal in mind

You’re both working towards the same end goal - an awesome end product! You’re not waging war against each other.

Deliverables:
Developer Handoff

  • Live style guide
  • Pattern library
  • Wireframes
  • Skinned design

A few resources

Attend

  • ArtifactConf
    • “ARTIFACT is an intimate two-day, single-track conference that helps web designers and developers adapt their tools and processes to the challenges of designing for a multi-device world.”
  • ConvergeSE
    • “Conference for those who want to build a beautiful web.”
  • An Event Apart
    • “The one web design conference where groundbreaking techniques break first.”

Bookmark

Follow

A Modern Design Process - Google Slides