Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
69 lines (34 sloc) 4.5 KB

Design and Front End: Couples Therapy

With Liam Oscar Thurston

At the foundation of any successful business are considerate and intentional relationships. They take understanding, compromise, listening, patience and consideration. In order to understand and empathize with others you need to start listening to what things people say… Relationships are work. But they’re going to be the most rewarding thing you could ever do or have in your work (and life).

Shit Designers and Developers Say to Each Other

What they say: "Oh, I thought you were going to do that."

What you should do: Set project expectations and own them. Understand the impact, time and effort goes into the project tasks. A Trello board is great way to kick off a project and to track who is responsible for what.

**What they say: **"So when are you going to do ___?"

What you should do: Do not work in designer/developer silos but pair up or sit with your project team. That way we learn how others work and what they are working on. If you are remote, try tools like screen hero.

What they say: [Silently, you are handed a messy file]

**What you should do: **Stand in front of a white board and agree on what the assets are called. Speak the same language when naming things. For example you could use the BEM framework for CSS can carry that over to how assets are named in Sketch. Use labelling conventions that are easy to look up. Discuss grid system you plan to use before using it. The goal at the end of the day is to build an amazing component based style guide.

**What they say: **"Hey, there seems to be some things missing from this style guide."

**What you should do: **Think through the complete interface state stack, e.g. error, partial, loaded, empty states. A helpful approach for this is to use job stories. We’re used to user journey stories but these tend to be epic, whereas job stories are discrete tasks.

What they say: "Hey, what’s with all the inconsistent white space?"

What you should do: Define small, medium and large spacer types and create visuals to denote which space is being used in the design on their own layer.

What they say: "Wow, the content is a little too perfect."

What you should do: You can use Craft with Sketch to bring in content to mock out, but use real content to get an idea of what the real experience looks like. Build around edge cases, not ideal cases.

**What they say: **"So you used about 50 shades of grey."

**What you should do: **Grey on grey buttons look great on your cinema display, but make sure you also look at things on your shitty lower resolution monitor. Engineers don’t want to label 50 shades grey so start with a constrained palette.

**What they say: **"Hey, I built that component I saw in Zeplin"

What you should do: Avoid time wasted due to building old versions. Designers, please keep your files fresh so the developer is not building something out of date.

What they say: "I’ll do some design QA tonight."

What you should do: Stay close. Designers, don’t leave design QA until the end of the project, but "always be QA’ing". Leaving it until the end results in 35 critical blockers in JIRA for your developer.

**What they say: **"Damn, that user testing session was great and we learned so much from that."

**What you should do: ** Invite your engineers to the user testing sessions too. They should be in the room as well. Come together.

The Agile manifesto is not just about building better software, but also about building relationships:

  • "Individuals and interactions over processes and tools"

    • Tools track our relationships but not build them.
  • "Working software over comprehensive documentation"

    • Discussions should be about tangible, working code, not documentation, and never document things before discussing them.
  • "Customer collaboration over contract negotiation"

    • Understand our clients' human needs and their business well enough in order to quantify value of you work.
  • "Responding to change over following a plan"

    • Long term planning in this industry is a tough go. If you’re planning more than a few months out you’re probably making stuff up. When planning, make sure you’re all in the same room though and adjust your plans according to that. Developers, take your headphones off from time to time and come up for air. Share your shit early and often and aim for radical candor in your conversations.