Journal


## New Year, New Job

Starting 2022 with a new job. January 4th will be my first day at PayPal as a Lead Designer. I'm joining a growing team that is going to re-envision the dot com side of the business with a best-in-class site. Excited for the challenge ahead. Wish me luck.

–JC


Heyo PayPal


Making a nav show and hide on scroll looks good. In the past, I've created a vanilla js version inspired by what Marius Craciunoiu wrote about in [this article](https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c) circa 2013.

I always loved this method, as it did what I needed it to do for many-a site, but javascript has changed a lot since 2013. With advancements within React with hooks, plus with new libraries like Framer Motion. So I found myself building the very site you're reading this on, which is a Reacjt JS Gatsby site, and wanted to find a more modern method to create this effect, which led me to a solution which I share here.

## Getting started

You'll get started with your basic app shell, if you already have a react project you'll have to adapt this to your project structure. Or if you want to follow along you can use this [create-react-app starter](https://codesandbox.io/s/x335plk7xo) on CodeSandbox.

First, you'll start in your root app layout, that will look something like this.

```jsx
// App.js

export default function App() {
  return <div className="App"></div>;
}
```

Okay, now you'll create the `Nav` component, for mine I put it in the root directory and called the file `nav.js`. In this `Nav` component I'm setting up a few simple things: 1) the base structure of nav, with a logo on the left and nav links on the right, 2) some base styles for the nav so it doesn't look terrible, and 3) I'm setting up a small array with `linkList` to `.map()` over in order to generate some faux nav links in a clean way.

```jsx
// nav.js
// Create this file and use the code below

import React from "react";

/** this is to FPO generate 5 links for the nav **/
const linkList = [{}, {}, {}, {}, {}];

/** nav parent styles **/
const navStyles = {
  display: "flex",
  position: "fixed",
  alignItems: "center",
  justifyContent: "space-between",
  height: "6rem",
  padding: "0 2rem",
  width: "calc(100vw - 4rem)",
  left: "0",
};

/** links parent styles **/
const navLinksWrapper = {
  display: "flex",
  alignItems: "center",
  justifyContent: "space-between",
  width: "50%",
};

export default function Nav() {
  return (
    <nav style={navStyles}>
      <span>Logo</span>
      <div style={navLinksWrapper}>
        {linkList.map((item, i) => (
          <span key={i}>Link</span>
        ))}
      </div>
    </nav>
  );
}
```

Once you create that `nav.js` file, let's import it into `App.js` and include it as a child of your main `div` wrapper. I've also added styles to give the page some height.

```jsx
// App.js

import Nav from "./nav"; /** import Nav **/

/** add this **/
const wrapperStyle = {
  height: "200vh",
};

export default function App() {
  return (
    <div className="App" style={wrapperStyle} /** include styles here **/>
      /** inlcude nav component **/
      <Nav />
    </div>
  );
}
```

What you should have at this point is a basic page with a fixed nav and and a scrollable body. Super basic stuff.

## Now the fun part

Let's add Framer Motion as a dependency. To do this run `npm install framer-motion` in your terminal at the root of your project directory. Once that's good to go, you'll import it into your `nav.js` file. It's also important to prefix your `<nav>` with `motion`, this will make your element motion component.

```jsx
// nav.js
import React from 'react';
/** import framer-motion **/
import { motion, useViewportScroll } from "framer-motion";

...

export default function Nav() {
  return (
    <motion.nav /** add 'motion.' prefix to 'nav' **/ ... >
      ...
    </motion.nav>
  );
}
```

Now we're going to use the `useViewportScroll` hook from framer-motion to get the scroll y-axis value. We'll also be using the react `useEffect` hook to fire an `onChange` callback for the `scrollY` value updating.

```jsx
// nav.js
...

export default function Nav() {
  /** add this bit **/
  const { scrollY } = useViewportScroll();

  /** add this useEffect hook to return events everytime the scrollY changes **/
  React.useEffect(() => {
    return scrollY.onChange(() => console.log(scrollY));
  });

  return (
    <motion.nav ... >
      ...
    </motion.nav>
  );
}
```

If this is working well, you should see this in your log:

```shell
MotionValue {timeDelta: 0, lastUpdated: 0, updateSubscribers: Object, renderSubscribers: Object, canTrackVelocity: true ...}
```

With the hooks working well we can make them trigger some state changes.

```jsx
// nav.js
...

export default function Nav() {

  ...

  /** add useState hook to manage state **/
  const [hidden, setHidden] = React.useState(false);

  /** this onUpdate function will be called in the `scrollY.onChange` callback **/
  function update() {
    if (scrollY?.current < scrollY?.prev) {
      setHidden(false);
      console.log("visible");
    } else if (scrollY?.current > 100 && scrollY?.current > scrollY?.prev) {
      setHidden(true);
      console.log("hidden");
    }
  }

  /** update the onChange callback to call for `update()` **/
  React.useEffect(() => {
    return scrollY.onChange(() => update());
  });

  return (
    <motion.nav ... >
      ...
    </motion.nav>
  );
}
```

If you look in your console, you should see "visible" and "hidden" events firing everytime you scroll up and down.

### Hooking it all up

Now we're going to interpret the `hidden` state boolean into animated states using a framer-motion method called `variants`. All we need to do here is set keys for each state (in this case, "visible" and "hidden") with their own style object. Once you plug in this code you should be excited to see this working!

```jsx
// nav.js
...

export default function Nav() {

  ... // removing for brevity

  /** add this const **/
  const variants = {
    /** this is the "visible" key and it's respective style object **/
    visible: { opacity: 1, y: 0 },
    /** this is the "hidden" key and it's respective style object **/
    hidden: { opacity: 0, y: -25 }
  };

  return (
    <motion.nav
      /** the variants object needs to be passed into the motion component **/
      variants={variants}
      /** it's right here that we match our boolean state with these variant keys **/
      animate={hidden ? "hidden" : "visible"}
      /** I'm also going to add a custom easing curve and duration for the animation **/
      transition={{ ease: [0.1, 0.25, 0.3, 1], duration: 0.6 }}
      ...
    >
      ...
    </motion.nav>
  );
}
```

### Here is the preview

And that's all folks. The result can be previewed below, or you can checkout the full example on [CodeSandbox](https://codesandbox.io/s/framer-motion-nav-show-hide-article-version-omnnd?file=/src/nav.js).

What we've made here is a super simple modern javascript method for showing and hiding nav elements based on scroll. You can even get more creative with the animation method by adding more properties to the variants object.

<iframe src="https://codesandbox.io/embed/framer-motion-nav-show-hide-article-version-omnnd?autoresize=1&fontsize=12&module=%2Fsrc%2Fnav.js&theme=dark"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="Framer Motion Nav Show Hide (Article Version)"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

—

Thanks for reading! – John


Make a Nav Show and Hide On Scroll


## As my time was ending at Happy Money, where I spent the last five years of my career, I began reflecting on the lessons I learned as a first time design leader.

In my five years, I worked with amazing people. The first three years of my tenure was as a design contributor and lead, and in 2018 I was promoted to Design Director of brand and product design. This was my first role ever running a team, managing people, recruiting for fast growth, and on top of all that maintaining a well strategized design operation for the business.

I learned _a lot_ in those two years.

A few things came natural; my desire and ability to create a thriving culture of diverse designers, a strategy for growing the org, and my deep and overflowing passion for design and creative. However, the list of challenges far outsizes all, which includes but is not limited to: team interpersonal conflict, company vision changes, attrition, leadership alignment, struggling to detach myself as a contributor, aligning brand and product design disciplines, creating and maintaining a coherent strategy, having to fire people, and adapting to being distributed during a pandemic; the list goes on.

As time has went on, so much has become abundantly clear to me on how a designer needs to lead. To be honest, many of my realizations are painfully simple, it's merely been the direct experience that has helped me truly realize them.

Out of my reflection I wrote about seven different lessons. They don't make a comprehensive list of all the things a design leader should know, but they're the most personally impactful lessons I can think of. I wrote all of them in a voice that speaks of my personal experience and is directed to any past, present, or future design leader. Here's what I've got.

<h1 class="post-text-num" data-num="1">1. Release your grip</h1>

When I became the leader, my sense of responsibility spiked. This covered all aspects of the team, and was something I saw as a strength. I treated the team like it was my own little company within the company. It made me want to be a design visionary, to make changes to process, to institute new team traditions, and more. Albeit, at the start the team was only myself and 1 other designer. Which meant that while I was this new aspirational visionary, I was still directly contributing. Later, when I grew the team to 5+ designers other than myself, I was still behaving like a part-time contributor. Sometimes coach and sometimes player, at my own whim.

While this tendency came from a place of positive responsibility, as an extension of my design abilities, it translated to the team as infuriating and disempowering. Thanks to a patient team, candid feedback from my team members, and some self awareness, was I able to see the negative impact that I was making. I was taking away from them what I so clearly entrusted them with, by bringing them into the team in the first place.

A good example (yet painful to recount) of when this happened, is when I was preparing to speak for a mini all-hands where I was unveiling the new brand to the company. At this point, I had 3 brand designers on the team, each with time to spend to help me put together collateral and materials for the event and presentation. Instead, I did it all myself. Where I _had_ recruited them, it was only for some small aspects, most of which I later took and made changes to, before the final unveiling (insert cringe ... hindsight is 20/20). In the moment, I was acting out of that deep sense of care and responsibility for the thing we were unveiling. But, I was not thinking or acting like a leader; I was thinking and acting like a designer. I felt great delivering the keynote, but afterwards, I realized that I had bulldozed my team.

Step one for me was to release my grip. Which doesn't mean that should throw out my responsibility or anything I care deeply for, but it instead means that I need to trust my people. By me releasing, it makes room for others to show their strengths, and even learn their own lessons through their own mistakes.

This act of releasing my grip was a repeated struggle, something I had to be very conscious of. I had patterns that I had built over years and years as a design contributor. Because of this, I would often try to seek comfort in those old ways and unconsciously slide back.

Great leaders aren't white-knuckling their teams into success, they're standing there with open hands letting their team do what _they_ do best.

<h1 class="post-text-num" data-num="2">2. Give designers ownership</h1>

This one has always been obvious for me, but my perspective changed when I became the leader of a team. I can remember as a young designer, pining for ownership and trust from my creative director or manager. Whenever I discovered that gift of ownership (sometimes by permission, sometimes by my own mindset), I could really sink my teeth into a project. As designers, we're opinionated and bull-headed. We became creators and shapers of experiences because deep down we have an audacious belief that _we_ as individuals can make things better. Often critical of ourselves and the world we experience, we constantly think "that could be better," to everything we see. We want to _own_ our own ideas.

So as the new design leader, it was natural for me to believe that I (now) was the owner of everything. While that is somewhat true, since I was the ultimately accountable individual, it's a perspective that is really disempowering to each individual designer. And believe me, even if you don't utter it, they _will_ feel it. The answer is simple, grant your designers clear ownership (or what I named "drivership") over areas of the experience. Set clear expectations, but hand over the keys. Over time, you will be able to tell that the designer feels a sense of ownership when you can see them take on a self given sense of responsibility.

<h1 class="post-text-num" data-num="3">3. Know your role and how you bring value</h1>

A misconception of these first two points (releasing your grip and giving ownership) is that you're totally hands off, out of the loop, and doing nothing at all. This is untrue. Your craft becomes the art of setting up expectations, leading work from a strategic level, and guiding your team members through their challenges.

When leading through guidance, it's best to let your team members discover their own conclusions. Telling them what _you_ would do is very tempting, because you've likely been in their situation. Instead ask an open-ended question, like "what do you think should be done at this point?" This will keep the keys firmly in the hands of the driver (not you), which is the ultimate tool of empowerment. This doesn't mean that advice or "telling" is out of the question, but I personally challenged myself to balance the ask-to-tell ratio in favor of "asking."

It may look different depending on team size or level within the design org, but the point is simple; know the role your team needs of you, this is your north star.

<h1 class="post-text-num" data-num="4">4. Promote your people</h1>

I had the greatest privilege of being able to hire and grow a team. This meant that, at first, I was the only manager in the design org; which grew into an untenable span of control very quickly, especially as a first time manager. At first by necessity, I had to raise people up on the team into manager roles to mitigate the challenge of my manager-to-direct-report ratio.

Two really simple distinctions at the get-go here, 1) not everyone needs to become a manager and 2) becoming a manager is not the only track for leveling up within a team.

That said, there will be people on your team (as there were on mine) that will be a perfect fit for the bill of rising up into managers of people. Sometimes there wont be, and it'll be an opportunity to bring in a manager from the outside. In my time as Design Director, I was able to promote four well deserving team members to the role of manager. Additionally, in my time, I was able level up a few other folks to new individual contributor levels. Let me tell you, there is so much satisfaction in sitting down someone on the team to level them up and giving them a raise, along with a new well-deserving role and charter. That might have been the best part of the job.

<h1 class="post-text-num" data-num="5">5. Managing friends is hard</h1>

Before I took the promotion to become the manager of the design team, I was good friends with the two guys who were my peers. When I became their manager our friendship dynamic changed. I was now meeting with them to talk about career growth and performance; and I was now responsible for their output to the business. If you can guess, this made things challenging. I felt awkward because I didn't feel like it was easy to be a friend and a manager at the same time. Since the majority of our interactions were work based, it was hard to jump between wearing both hats. When I look back, I completely empathize for the situation there were in; it was uncomfortable.

There however was a difference for new team members that joined, they got to know me first _as_ manager, which made things far easier. The best thing that I did with those who knew me before, was to just level with them about how weird it was, and try to be as human as possible. I even had dinner with one friend, where we vowed to not at all talk about work at all, and it was a great step forward.

No grand lesson here, just a cautionary anecdote (thanks for being awesome David and Scott).

<h1 class="post-text-num" data-num="6">6. Everyone is different</h1>

Yeah, no duh. This is an obvious one, but it's something to highlight when it comes to managing. There is an old-held misconception that contributors or direct reports on a team need to adapt their behavior to match up with their managers. This comes from a bygone era of a "get on my level," Don Draper-eqsue way of leadership. It's bullshit. Leaders are ultimately servants of their people, and need to adapt their style of leadership to meet each individual. There _is_ a good model of this that I really like called [Situational Leadership](https://situational.com/situational-leadership/), where the leader/manager changes their approach situationally from directing, to coaching, to supporting, and ultimately to delegating. It's worth looking into, as there is tons of literature on the subject.

The more important lesson for me was one of humility. It takes self awareness and preparation to come into a one-on-one with a team member and meet them as individuals. I'm still very much so a student of this task, and still learning how to practice it as a leader and a peer.

<h1 class="post-text-num" data-num="7">7. Get a coach</h1>

Just over one year into being a design leader, I was feeling wayward and in need of guidance. Since I was the top design leader in my organization, I didn't have anyone with design leadership experience to lead and guide me through the challenges I was facing. That's when I came across the [Design Dept.](https://www.designdept.co/), they're a women-led design leadership community that offers coaching and workshops. I instantly sent out an inquiry about coaching, and not to long after I was paired with my coach, and haven't looked back since.

My coach has been instrumental in helping me navigate the challenges of being a design leader. In fact, much of the reflection contained in these lessons is directly from conversations her and I have had.

Having a design leadership mentor and a coach is crucial to circumnavigating the challenges of leading a team of designers. Having someone who can speak from deep experience about the things you're actively working through is a _must_. Leadership positions can be lonely, and it's not always best to confide in your direct reports about the toughest challenges. While there is a cost associated with this type of coaching, any organization that cares about the professional development of their leaders will make the investment.

---

Well, what do you know. That's all I've got.

I'm so insanely indebted to everyone who helped make my experience as a leader a thoughtful and fruitful one. Thanks to my design leadership coach [April Neufeld](https://www.linkedin.com/in/aprilneufeld/), I'm grateful for everything your insight and perspective brings to me. Shout out to my former manager and CPO of Happy Money, Adam Zarlengo, thanks for your support and trust in my ability to lead. I also would not have learned the lessons that I did, if not for my former team. Shout out to David Garvin, Scott Branch, Sally Alvarado, Sar Issagholian, Kathy Speer, Jonathan Wagoner, Sarah Ohye, Mark Hsieh, Kristine White, Joey Belardi, Jeff Weimer, Laura Zinssmeister, and Cat Freeman. Thanks for bearing with me, as I was figuring out my shit.

–JC

![lg](/images/journal/design-leadership-cover.jpg)


What I Learned From Two Years as a Design Leader


## Good Bye, Happy Money

Next Tuesday is my last day as Design Director at [Happy Money](https://happymoney.com). I've spent the last 5 years working for an amazing mission-driven company, gaining so much personal growth on so many great projects. I'm so honored to have had the opportunity for the last two years to lead the Brand and Product Design teams. It was my ultimate pleasure to be apart of growing and scaling the design org into a flourishing team of talented individuals. No doubt, some of the best people that I've ever worked with; they're all going places and I can't wait to watch, now from a distance.

## Hello, GoDaddy

Starting on September 21st, I'll be joining GoDaddy as a Principal UX Designer to work on the shop experience. This new opportunity entered my horizon, and I'm so excited to be joining an expansive world class team. GoDaddy caught my eye in recent years with their massive brand reinvention. Even more so, since the pandemic, seeing how they've directed their business and purpose to become mission driven towards small businesses affected by COVID. I'm beyond excited to be joining up to contribute to such a transformational brand at such a pivotal time in the world.

I'll be joining the team as a full-time remote team member, working from my backyard studio office in sunny (currently smokey) Long Beach, California.

Here's to moving onward.

–JC


Hello GoDaddy


## Let's get real.

## So much of what it means to be a designer today is in and around the computer.

## There is "edit, undo."

## Version history.

## Multiplayer collaboration.

## Design systems.

These things are not bad. They enable us to be faster, systematic, and more efficient designers.

While you can be extremely creative within those systems and tools, it's a little different than the tools and frame of mind from our art education (remember that BFA that we spent 100k+ on?).

--

## Mark making.

## Figure-ground.

## Expression.

## Decisions.

## Experimentation.

About 4 months ago I started going into the garage late at night, while my wife and baby daughter were asleep, to create artwork.

I want to be clear, I cringe a little inside when I say "artwork," because I know how it sounds. But, that's what it is.

These aren't designs. These don't have a problem they are solving. They don't serve a function. These are expressions and feelings put on paper.

At first, they felt like large scale doodles.

I started there, for the most part, just putting down marks that reflect what I'd naturally doodle.

Then the fear came.

## What do I make now?

## How do I know where to make the first mark?

## How will I know what looks good?

## What if I mess up?

## Why does it matter if I mess up? (oh, right, I'd be wasting material)

## What if I just lean into it? (you mean, if I just don't care?)

![twoup](/journal-gif/garage-02_0.gif)
![twoup](/journal-gif/garage-02_1.gif)

So much of the beginning was struggle. I wasn't really sure where I was going, or what I would make.

I would just _begin_, and that's when magic happens.

With a piece of scrap wood on the table (yes, I started with using scrap wood laying around the garage) I begin a small mark-making exercise.

It was some of the most insignificant/useless pieces of wood that gave me permission to let my guard down. Most of which turned out to be the coolest pieces I made.

A large, store bought canvas carries an expectation of "don't fuck it up, you just spent \$30 on me, and this better be damn good."

So I bought some cheap large format paper to do large-scale sketches.

And then peace came (even if just a little bit).

## I don't know what I'm about to make.

## I'm just going to start.

## This is about play.

## I'm going to let myself make mistakes.

There is no brief, no plan, no edit > undo, no system; just your body, a tool, and a surface.

![twoup](/journal-gif/garage-01_0.gif)
![twoup](/journal-gif/garage-01_1.gif)

## Making art is about decision making.

I'm constantly in the struggle between the fear and peace of putting marks down on the page. Pushing forward some abstract intuition; creation with zero plan in mind.

Some of the time I do start with plan, but the best ones come naturally, like a gesture.

--

## Our digitally designed world is that way it _is_ so we can apply our craft very usefully to various enterprises and businesses.

## It's survival, and I love what I do.

## But...

## I was needing a space to _just_ create.

## In the garage.

## Late at night.

## Family asleep.

## Just me, a tool, and a surface.

--

![xs](/images/journal/Line-Series-01.png)

--

Thanks for reading.

You can check out more work [here](https://www.instagram.com/johnchoura.art/).


In The Garage


"Stack mirroring: Designing for code and coding for design" was originally written for and published by [Design Systems](https://www.designsystems.com/), [read the original](https://www.designsystems.com/stack-mirroring-designing-for-code-and-coding-for-design/).

## Let’s be honest, design systems are doing what code has been doing for a long time now.

## Programming by nature is functional, reusable, extensible, and version controlled. Modern design systems aim to accomplish much of the same and more, and therefore can take direction from how programming already functions.

Design systems are important because they enable faster design iteration, team and product scalability, and programmatic thinking. I’ve always been onboard with the first two, but it’s programmatic thinking I’m currently most interested in. Thinking programmatically when building and implementing design systems gives superpowers to product design teams.

# Mirroring code structure in design files

Here’s an example I came across most recently. I was building a UI component library in Figma for our web apps. Our UI Engineering team had already built this component library in React as an npm dependency. Since I was already familiar with React, I started working backward by using the React component code as inspiration for building the Figma instance. I immediately saw the benefit of isolating and nesting components of all sizes, and accounting for all options and props that exist in the React schema.

![lg](/images/journal/JC_2.png)

For years I had already been modeling layers and groups after markup – nesting, ordering, layer naming, mirroring class names – so mirroring code structure in design files didn’t seem like a crazy idea to me. I did have the luxury of starting with the code first and working backward, but the lesson stands. There is power in design mirroring code and vice versa. It begins to further approximate the actual with the static.

In the example above, I’m using a series of nested components to mirror how we construct a form input. It goes like this FormGroup > Input > Label. Input and Label are their own master components. These instances of Input and Label are then bundled in the master component of FormGroup. Similar to React, this allows for the independent management and integration of the component. When handling a component that can have multiple variations or when trying to simulate React’s “props,” a simple on/off toggle will suffice.

![lg](/images/journal/JC_1.png)

# Stack Mirroring from a dependency level

Markup mirroring is fine and dandy, but I don’t want to stop there. I see an opportunity to further mirror our front-end code stack (Node, npm, React, Javascript, markup, etc.) with our design stack (Figma, Figma Libraries, Figma Components, layers and groups, etc.). Enter my idea of “stack mirroring.”

Before I was mirroring on the element level, but now I’ve started thinking about how to mirror on the dependency level. Platforms like npm enable the limitless inclusion of externally managed packages and dependencies (learn more about npm here). For example, the component library I mentioned earlier is a dependency we call Happy UI. This is a front-end component library that is shared across our web products, not unlike Figma’s shared libraries. This alignment is another obvious opportunity to leverage mirroring.

![lg](/images/journal/JC_3.png)

Just as dependencies can be included on a package.json file in a node project, you can think of Figma’s Team Libraries the same way. We’ve separated our Happy UI dependencies into a few different projects: Core, Web, and Native. Happy UI Core has shared fundamentals like brand assets, colors, icons, and utility components. Happy UI Web has all of the functional components to build a web interface and when combined with Core, we’re cookin’ with gas. So if I’m working on a new onboarding flow for the web, I’ll use Web and Core and it’s as easy as that.

When working with our UI Engineers or Software Engineers, we use a shared namespace and model to facilitate scalability, efficiency, and iteration in our fast-paced environment. With stack mirroring, there is less panic and confusion around the ways and means to accomplish these goals.

I believe that design and development work better together when our namespace, tools, and models are in sync. When we reduce mental overhead, teams don’t have to compromise on quality, even while they build and ship features fast. Keeping development and design concurrent means your product is easier to maintain, test, and update. What are you waiting for? Work with your developers to start stack mirroring today.


Designing for code and coding for design


### How ordering information hierarchy can make or break an interface experience

## The Hierarchical Powers That Be

When I think of hierarchy, a power struggle comes to mind. Something straight out of a medieval times throne-grabbing Game of Thrones-esque story. Every pawn and piece is at play competing for a chance at the top of the stack, at all costs.

Sure, I’m talking in reference to user interface design, and yes this framing might sound a bit lofty, but stick with me. When it comes to designing interfaces it’s worth while to consider that every intention and decision in a layout of elements is a power-grabbing battle for attention. There’s only room enough for one queen bee in this game…er…um…interface.

## The Task of Hierarchy

We recently updated the interface for the Joy app, updated typography, colors, and some layout. These changes were mostly for a visual brand update, but we use the layout improvements was to improve the usability hierarchy.

Really quick, I just wanted to pause and say that thinking about hierarchy gets me nostalgic. These ideas tap right into my formal design education; where the hierarchical task is the basic endgame of the classic design principles. We employ color, weight, contrast, scale, movement, etc. to accentuate this hierarchy (or lack thereof). Designing posters, print layout, video storyboards, environmental spaces, ad units, and just about any functional form employs hierarchy.

## Get Squinty

Back to my task at hand. As an anecdote, take a look at these original screens in Joy to get a picture of where I was starting.

![lg](/images/journal/ui-hierarchy-1.png)

I completely desaturated and progressively blur the image to simulate the squinting and blurring of the eyes. This is a little trick that I do when working to spot areas in the screen that are fighting for that hierarchical throne. I squint A. LOT. when I’m designing (especially kerning), it helps give me the ability to sense the heavy areas of a particular design. In this given instance I count about 4–6 elements that are battling it for the queen spot.

The issue with the original interface is that your eye bounces around in circles looking for a resting place. It’s in these resting places that we find our queen hierarchical element(s).

As this exercise has simulated, I’m able to clearly diagnose this issue we’re having and tangibly solve for them. Here is where we landed for the final design of the spend rating screen.

![sm](/images/journal/ui-hierarchy-4.png)

There was a choice to soften the lesser important areas and add/maintain weight for my target resting area. In this case that area lies in the primary action (the happy/sad buttons). Taking the text and resting it in the header image helped soften the dominance while maintaining visibility. We also flipped the vertical order of the chat conversation starters and ditched the open/close mechanism.

![lg](/images/journal/ui-hierarchy-2.png)

In the simulation of eye blurring, you can see elements don’t blare through with the same harsh dominance as the it’s predecessor. The eye can rest and no longer spin looking as it looks for that hierarchical queen space.

Just to be clear, I don’t think the idea the hierarchy existing in a user interface is a novel idea. For me it’s a powerful reminder to evaluate whole interfaces and screens with this method. It’s our mission as a product team to always improve the work we put out into the world. Products are never done. Additionally, for those who don’t have a formal design background I hope it’s a new and useful exercise.

Thanks for reading!

--

** This article was originally published on the Happy Design Team publication, you can [read that here](https://medium.com/happy-design/user-interface-hierarchy-291f279ce9ad). **


User Interface Hierarchy


### 4 Lessons Learned Building Joy with React Native

It’s been a year since our mobile app Joy was publicly launched, and it has me getting reflective. As a product Joy has been my baby, I’ve been with it from the beginning and have been honored to help it grow into what it’s become. A lot of that journey has involved me getting hands dirty with code and using React Native to build the UI for the app. Being that I’m a designer and this was my first foray into React Native(or even React), I thought of 4 take-away’s.

## 1.👏Com👏pon👏ents👏

This comes as no surprise to those familiar with React and React Native (and really, the web for the past few years), but as designers are increasingly fixated with building better and more efficient design systems, componentized code just makes everything amazing. I believe what designers are aiming for when making design systems in static form, is fully actualized and realized with componentized code.

![sm](/images/journal/01-joy-rn-2.jpg)

Extensible to no-end, thinking in components is a productive mindset for a product designer. Take, for example, a simple button. A button isn’t so simple, because in any app, a button changes based on context with what’s happening on that particular screen, so instead of building 14 buttons, we build 1 component with a whole bunch of options (as “props”).

![xs](/images/journal/01-joy-rn-3.jpg)

When adding and removing props, which function as a basic true/false statements, there are styles within the component that are selected/unselected. Choosing an option like isInverse will invert the colors on the button, or isDisabled will dim the button and disable it’s onPress function.

I use a button as my example because the “button” is a quintessential piece of UI. Some designers even overly-obsess over button consistency, accuracy, usage, etc. With how these components are structured, it’s really hard to mess up using buttons. Peace of mind for those button-centric-type-a designers.

With components, I should clarify and it goes with out saying, that this thinking is not exclusive to React; component based apps and website development is very much a thing and for good reason. Code is best when it’s reusable, and that’s what components afford a well written app.

## 2. 🤩 Marveled by CSS-in-JS

Before React Native, my work was web development exclusive, so I understood markup (HTML) and styling (CSS or SCSS) pretty well. For some time leading up to the start of Joy, I was nervous at the prospect of styling React Native, I was unsure what that would be like. But, oh boy, was I relieved once I found out that I could use “CSS-in-JS” for all my styling needs. CSS-in-JS really bridged the gap for me.

Without getting to explain-y and probably getting some of the technical parts wrong; simply put, CSS-in-JS is what it exactly sounds like. The React Native team and community translated almost all of the CSS properties (font-size, transform, z-index, position, flex-grow, etc.) into JavaScript (fontSize, transform, zIndex, position, flexGrow, etc.). The largest difference being that the property names conform to camel case, and the syntax structure conforms to JSON. If you’re curious at the details of what they did watch this video, it’s a great explainer.

![xs](/images/journal/01-joy-rn-4.jpg)

You get to leverage the full power of Flexbox for all layout purposes, which I wasn’t super good at going into the project, but now I’m well versed.

All styles are localized to components, and we use a global variables doc that holds all of the colors, spacing increments, font sizes, etc. With this, there is less of an intense need to have global stylesheets.

One of the greatest strengths of CSS-in-JS over Sass/SCSS is the ability to have a global namespace. Since it’s all javascript, variables for styles can be used in functions and functions can be used in styles. This minimizes redundancy of re-writing logic or variables for different languages.

## 3. 🤓 Embrace JSON

This one is less React Native specific, but it’s a lesson I learned none-the-less. So I’ll just say it, I’m convinced, every designer (or non) working on digital products should know how to write JSON. Period. It’s a great way to structure data. It’s what API’s spit out, and it’s just some damn essential stuff. I’m kicking myself that I didn’t understand it sooner.

When building for Joy, I would often be designing and writing product requirements in tandem. Often those requirements involved some data structuring decisions. For example, if I was working on an array of transactions, I don’t want to hard-code those individual transactions. Additionally, I also have to define the data structure for how transactions would return. So I rolled up my sleeves and just wrote the data structure myself.

![lg](/images/journal/01-joy-rn-5.jpg)

I looped through that array of transaction objects in my JSX code, and voila! it rendered as my array.

The basics (engineers skip this part) are that there are objects and arrays. Objects are wrapped in curly brackets{} and arrays are wrapped in square brackets [].

![xs](/journal-gif/01-joy-rn-6.jpg)

It’s important for designers to start thinking this way, because it can bridge the gap between designers and engineers when there is sample data to talk through. Knowing the difference between strings, bools, and functions respective to a JSON table is also important. Read up designers.

## 4. 🤪 Animated Animations

A daunting question I had when heading into React Native development was “how am I going to make things interactive and animated?” I had no idea, but I had a guess that I could. My initial Google searches of “react native animations,” surfaced very few results. However, there was one pattern that kept popping up and it was this guy Jason Brown. He, at that time, was (and… still is) the de-facto thought leader for all things animated with React Native. I mean, sure there was Facebook’s docs, but they had no examples that I could use to wrap my head around.

So, admittedly if it were not for Jason, his Egghead tutorials, his website, the animation book he wrote, and his responding to my desperate tweets, I’d be totally lost on how to animate anything at all. Shameless plug, this guy is the godfather of this stuff. 🙌

Here are a few things I built using React Native’s Animated libraries.

![lg](/journal-gif/01-joy-rn.gif)

## Wrapping it up

All of these lessons are just the tip of the iceberg in a long list of benefits that I discovered when building Joy. Excited to keep learning more as we keep making Joy better. Also, I’m NOT claiming React Native is the best framework for compiling to native code, but it’s a goodie.

Thanks for reading!

--

** This article was originally published on the Happy Design Team publication, you can [read that here](https://medium.com/happy-design/designer-meets-react-native-159266fb7b3c). **


Designer Meets React Native


Just a little itty-itty announcement, my wife Alex and I have started on the most amazing project of our lives by welcoming our little daughter Elle (pronounced "L") Joy Choura into the world.

She was born on August 1st, 2018 and she's an amazing little chunk of cuteness. I'm only two weeks into her being here, and I couldn't feel more blessed to be a dad.

Fun nerdy Dad fact, her name is a palindrome, and so is her birthday (Elle and 8.1.18). 🤓

![sm](/journal-gif/97a80930-f631-485f-828f-5b48f20d7150-animation.gif)


Meet Elle


# Last year my wife Alex and I did some work to our house. I love it some much that I just want to brag about it. 😀

Home is something that's hard to explain, but we've had the opportunity to make something really amazing that I'm so proud to call my "home." As a designer, designing for a physical environment/living space presented a whole new set of exciting challenges.

# 🔨

### We Started From This

![lg](/images/journal/home-before.jpg)

# 💻

### Rendered Some Plans with SketchUps

![lg](/journal-gif/home-vid.gif)

# 💪

### Work work work

After 4 months of working with a contractor, plumbers, builders, electricians, engineers, dry-wallers, we worked hard to make our dream home a reality.

![twoup](/journal-gif/home-timelapse.gif)
![twoup](/journal-gif/home-timelapse-02.gif)

# 😍

### And Ended With This

![lg](/images/journal/home-yard-sq.jpg)

200 addition square feet to the house by adding on a bathroom to the master bedroom. Our outdoor living space is equipped with an outdoor fire pit, built-in bbq countertop with mini fridge, and an above ground jacuzzi. To create our newly hardscaped space we poured 2 truck loads of new concrete, laid down new sod grass, and did custom landscaping with new display rocks and succulent plants.

![sm](/images/journal/home-full.jpg)
![lg](/images/journal/home-deck.jpg)
![lg](/images/journal/home-firepit.jpg)

![twoup](/images/journal/home-kitty.jpg)
![twoup](/images/journal/home-puppy.jpg)

![sm](/images/journal/home-chairs.jpg)

Doing work on our home was one of the most fun challenges that we've experienced as home owners. The process is stressful and exciting, coordinating and project managing contract workers. In the end it all pays off, and we get to enjoy the fruit of our labors.

🙂 That's all, at some point I'll write a follow up post showing what we did to the interior. Thx for reading.


Home Sweet


## I'm going back to school... But, errrr uh... probably not in the way you're thinking.

## I'm going back to teach!

This spring I'll be tromping back to my alma mater (Biola University) to teach as an adjunct professor of design. This has been in the works for a while now, and I can't express enough how honored I am to be taking this up.

I'll be instructing one night class, to start off, so as to not interfere with my role at Payoff. I do have a lot to say, as it relates to the importance and place of education for designers. I'll write about some of that, as well as posting updates happening in the classroom. Stay tuned for that in the near future.

One last thought! This all wouldn't have happened if not for the mentorship and guidance of Daniel Chang, the head of the design program at Biola. He's entrusted me to take over his classes while he's out on sabbatical, I promise to do my best.

![xs](/journal-gif/to-teach-3.gif)

###### Credit: Adam Sandler's _Billy Madison_ for the "Back to School" gif.


Back to School


## My wife and I took a little vacation to Sedona, AZ, and here are some of our favorite photos from the trip. Enjoy.

![sm](/images/journal/Sedona-New-sm-2.jpg)
![lg](/images/journal/Sedona-New-sm-3.jpg)
![sm](/images/journal/Sedona-New-sm-4.jpg)
![xs](/images/journal/Sedona-New-sm-5.jpg)
![lg](/images/journal/Sedona-New-sm-6.jpg)
![lg](/images/journal/Sedona-New-sm-7.jpg)
![xs](/images/journal/Sedona-New-sm-8.jpg)
![xs](/images/journal/Sedona-New-sm-9.jpg)
![sm](/images/journal/Sedona-New-sm-10.jpg)


Sedona Trip


## Once again, my wife and I took ourselves on a little trip to San Francisco for our anniversary in April. The last time we went to SF was two years ago for our two-year anniversary.

We've been married for four years, and together for almost seven years. She's the best! This time around was a blast, as usual. We saw friends, ate delicious food, Uber'd a ton, drank a lot of coffee, and took a lot of photos. The following are some of my favorite snaps from the trip. Enjoy.

![lg](/images/journal/20160506-sf-2.jpg)

![lg](/images/journal/20160506-sf-3.jpg)

![lg](/images/journal/20160506-sf-4.jpg)

![lg](/images/journal/20160506-sf-5.jpg)

![lg](/images/journal/20160506-sf-6.jpg)

![lg](/images/journal/20160506-sf-7.jpg)

![lg](/images/journal/20160506-sf-8.jpg)

![lg](/images/journal/20160506-sf-9.jpg)

![lg](/images/journal/20160506-sf-10.jpg)

![lg](/images/journal/20160506-sf-13.jpg)

![lg](/images/journal/20160506-sf-14.jpg)

![lg](/images/journal/20160506-sf-15.jpg)

![lg](/images/journal/20160506-sf-16.jpg)

![lg](/images/journal/20160506-sf-17.jpg)

![lg](/images/journal/20160506-sf-18.jpg)

![lg](/images/journal/20160506-sf-19.jpg)


SF Trip v2


I'm excited to announce that next week I'll be joining [Payoff](https://www.payoff.com/) as a Product Designer. I'll be working with [Josh Hemsley](https://twitter.com/joshhemsley) and the Payoff team to build out their brand, and mobile products, and ultimately reenvision the world of personal finance. With this new move it will be difficult to leave my friends and teammates at Envoy, a group of some of the most talented and quality human beings that I've had the pleasure to work with. But, times change, and I couldn't be more excited.

The balloons in the header of this article were hand-crafted by me entirely out of CSS/JS. If you want to see how I made it, check out the [Codepen](http://codepen.io/jchoura/pen/vOvrJv).


Joining Payoff


This is a story about my maternal grandfather, _Walter Clifford Dix_. Born in 1918 and grew up near and around the Ohio area. He eventually ended up serving in the army until 1943, and after that, went on to earn a degree in engineering from USC. He then spent the lump-sum of his career working as an industrial engineer at [Rockwell International^1](#refer) in Downey, CA contributing to the Apollo space program. He was a precise and intelligent engineer. I'm told he designed and wired control panels for the spacecraft.

When he wasn't working though, he would sketch, draw, paint, and doodle. On almost anything and everything. We still have his notebooks, loads of notebooks, filled with all these little sketches. In my mind he was truly the meeting point of an engineer and an artist.

![sm](/images/journal/notebook.jpg)

As a young boy, I have a clear memory about my grandfather teaching me how to draw. I have this distinct image in my mind of his little house that he lived in for 50+ years, with those half-drawn curtains and the way light came through, and that distinct musty old-man smell. I remember knowing that he could draw and paint, and I would ask him to draw a pictures of me; little 6-or-younger-year-old me. It was like a magic trick. He would move his hand across his notepad, with no effort. And with anticipation, I would wait for that moment when he would flip his page around, and show me what his pencil markings had made. I was always mesmerized and it made me determined to learn to draw.

His line work was shaky, not _just_ because of his age, but it was his style. He would gesturally move the pencil over, across, down, and around the page, almost in a tentative sense, in order to layer with light pencil strokes. He was trying to mirror what he was seeing with his eyes on the page. It was each of those combined movements, that would fashion the figure he was seeing.

Back then, my drawing trouble area with drawing people was always the human mouth. I mean it's essentially just two tube-like things stacked, right? Nope! This lesson always stuck with me, he told me, "Look at the light ... the upper lip is always shadowed, and the lower lip is always lighter." His lesson to me wasn't to teach me to draw shapes, he was teaching me to draw the shadows responding to the light. No more would I draw the mouth as two side-ways banana-like shapes, with a bunch of little chunky teeth. It's the light that shapes everything, and drawing is a matter of seeing the light and the space around it. I didn't know it then, but he was teaching light logic to a 6-year-old. I love that.

![xsm](/images/journal/apollo-img.png)

I can point back to these moments as a child and fully recognize them as my point of origin as a designer and an artist. These lessons laid a foundation for who I am.

He was an engineer and an artist, which means he had to think very logically, but he had an equal capacity to be imaginative. Those two had a meeting point, and an overlap in what he did. I think the virtue is the same for designers. A designer must, at once, be an artist and an engineer. The artist is open to the multiplicity of directions, welcoming to the subjective. The artist is an emotional intellectual, and for them there are no bad ideas, just a sea of ideas. The engineer is deliberate and objective. Always pursuing and hounding out a material understanding of the governing laws and ideas surrounding the artifact they are creating.

When these two paths of thought meet, they are lanes on a highway of thinking that function like a binary. The slowing of one lane means you can switch the opposite side, and continue solving the problem at hand.

Whenever I talk about design or vocation, I'm always led back here to this dichotomy of the designer. It's the meaning behind _Object & Subject_. I love it because it wraps what I do in a nice mystery, and doesn't allow it to be boxed in, rather it give me highways of thought that I can always tap into. And I'd like to think it all started back there with grandpa, learning how to draw. He may have passed away when I was young, but part of him moves forward within me.

Here is to you grandpa. 🍻

![lg](/images/journal/05-GP-poster.jpg)


The Engineer and the Artist


Around this time of year, I take the time to examine myself. Look in the mirror and ask the hard questions. I originally did this for the first time just over a year ago, and the exercise led me to the position I am in now.

Essentially I take a look at what I've done and where I've come in a year's time. I search for a renewed understanding of why I do what I do and look for the essence of why I am a **designer**. This investigation begets a force that powers and charges my personal and professional life. Additionally, I take the time redesign and rebuild my personal website. For me, this exercise of understanding is best represented in a public declaration (ie. this space). I understand that the sum of who I am is not represented here. And I know full well, that this space does a poor job showing my weaknesses, personal issues, etc. What it can show is the work that I have made, and how I made it. That makes for good reflection, even if it's not the full picture.

The findings of my search are simple, I am a designer of many disciplines. I believe that anything that enables me to make ideas a reality is deserving to be called design. It's in the means to that end that I find a child-like excitement that drives me. It brings me to reflect on this quote from Saul Bass.

> “Design is thinking made visual.” **-Saul Bass**

I've noticed that there is an unsettling feeling within a designer, with regard to the things they create. I notice this within myself too. It's this liminal space between the excitement of making and the discontent of what it lacks. The reason being is that as the creator, we have this broad perspective that the artifact we made, could have been better, or easier to use, or even more beautiful. These thoughts could drive us to despair, or emptiness if we allowed it to. For me, it's a driving force. A choice to push forward. It can stoke the flame, and create passion, teaching us to learn from our mistakes and failures. Both the obvious, and the invisible ones; those flaws that only we can see (_the could have been's_).

Everything we create starts with a thought in our mind. Designing is our conduit for making those thoughts a reality. I, as well as many other designers I know, understand that the only way we can express ourselves is to create and create well. Sometimes we make things and put it out in the world, but deep down we know that it's not exactly the image we had in our minds. So we press on, eager to create better what we see behind our eyes.

![lg](/images/journal/06-new-poster-art-01.jpg)


Staying in Motion


My wife and I, on a whim, decided to celebrate our 2nd year of marriage in San Francisco, CA. Our plan was to fly in, walk the city, eat some food, see some sights, and drink a lot of delicious coffee (the coffee part was my personal plan). So I decided to write this, to detail a few of the highlights, and recommend our favorite moments from our time in the city. It's a short story of love, adventure and very-very sore feet.

![sm](/images/journal/02-01-Ferry.jpg)

### Ferry Building

I had set my sights set on [Blue Bottle Coffee^1](#refer), and eagerly waited in their long line for a cappuccino. It was an experience at most, but I as a bit underwhelmed by the flavor; high expectations probably got the better of me (their [Mint Plaza^2](#refer) location, was better in my opinion). I will say, though, their [Ethiopia Yirgacheffe^1.2](#refer) was killer on drip, but I digress. Moving forward, for a tasty lunch, we had a sandwich and a salad at [Cowgirl Creamery^3](#refer). Good stuff, their cheese is phenomenal, and dream-worthy.

![sm](/images/journal/02-02-Mission.jpg)

### Mission District

For breakfast on Sunday, we happened across [Café St. Jorge^4](#refer); it was a great little café. We walked off our breakfast with an impromptu hike over the Bernal Heights Park. On the other side we walked down Folsom street passed by [Title Case^5](#refer), and traipsed through some stores. For lunch, we ate at the famous [Tartine Bakery^6](#refer), and bought a huge loaf of bread. Alex was so excited to eat here, she's been trying her hand at their sourdough recipe for a while, and was jonesing for a taste of the real deal. She was, of course, in heaven. Then a quick swing by [Four Barrel Coffee^7](#refer), and got a cappuccino and a bag. Yum.

![lg](/images/journal/02-03-Walking.jpg)

### Walking

There is nothing better than putting one foot in front of the other, and burning off some freshly consumed calories. Public transportation was a bit shaky for getting around, I mean, it's great if you really dig the smell some random dudes arm pits or piss. Not really our preferred option, which is why we gladly opted to walk, with just a few bus rides for the long haul. Be sure not to make the mistake of wearing bad walking shoes. One of the nice walking moments was through Alamo Square Park, which is where that family snapshot takes place in the "Full House" intro. Lovely, just lovely.

![sm](/images/journal/02-04-Exodus.jpg)

### Exodus

In a nutshell, this trip was short and sweet. We explored a small handful of other touristy places, and rode a trolley, of course, but never ended up making our way to the Golden Gate Bridge. On our way out of SFO, I had this serendipitous observation. Backstory; before our trip I made a small illustrated postcard (at the very top of this page), of the bridge sticking up through the clouds. So when our plane flew over the top of the city, my eyes were focused on seeing the bridge. Lo and behold, off in the distance was two [small red specs](https://www.dropbox.com/s/pfm75nlvhutbcnm/Screenshot%202014-04-21%2007.43.40.png) sticking up through the fog, which was rolling in. This trip was a huge blessing for Alex and I, It helped us prove to ourselves that we can make a lot of good memories out of a weekend. It has also encouraged us to explore our own local cities, in the same fashion as we did with San Francisco. Perhaps we'll see you again soon.


SF Trip


Let's take time to make some introductions.

Starting with this year, I'm working under a new moniker, **Object & Subject**, for my personal workspace. It's a home for my portfolio, a few little side projects, collaborations, and a bit of bad writing. For about 3 years now I've managed a handful of freelance gigs on the side, under my own name (J. C. Jr. Design). I've worked with some great people, on a garden variety of projects and ideas, and hope to continue to do so.

### The Site

The purpose behind this website, is that I wanted a new challenge. I had also grown unhappy with the limitation that pre-made template services offered. CSS injection is dull, and I wanted to start at a more grassroots level. All of this was unexplored territory. I knew that I would need to learn some basic front-end development, take a deeper plunge into HTML/CSS, and do some research on RWD and grids. Having come out the other side, I do so with a great deal of reflection, and humility. One of the greatest take-aways, is the realization that when I design for the web, I stand on the back of giants. I read a lot from folks like [Trent Walton, Jessica Hische, Noah Stokes, Jonnie Hallman, Skylar Challand, and Oak Studios^1](#refer) (who created [Siteleaf^2](#refer)). Each of these people have helped shape how I see, and design for the web.

### The Name

This studio is a dedication to my personal obsession with the words **object** and **subject**. For me, these are two of the most ripe words that I've ever come across. I know, I know, that's a big claim. But, each word carries with it, many differing synonyms/meanings. One can hold an object; object to an idea; seek objectivity; and have an objective (a physical thing; an opposition; a definition; a goal). One can also explore a subject; be subjected to something; embrace subjectivity; and be subject to certain ideas (a topic; a constraint, an instinct, and a proclivity). I hope you can see how nuts these words are.

Put together, they represent the paradox between a person's capacity to be both a thinking, and feeling being. I obsess over these connections, because of it's meaning, for how to live my vocation; design is both a science and an art. It's my true north. I want to design systems, but I also want to make aesthetic artifacts.

This is all to say, that I want to step fully into my vocation. In the coming years, I want to get to know the people that I find inspiring; hopefully even some of the folks I listed above. Most of all, I want to live a meaningful and balanced life. I'll end with a quote, thanks for reading.

> "I want to make beautiful things, even if nobody cares." **— Saul Bass**

![sm](/images/journal/01-objsbj.jpg)


Most Recent Post