An Approach to Show Designs & to Code Pages

Phase 1 of Design

Different design directions as we currently do to choose and lock down aesthetic choices. Tech weighs in on designs as normal (perhaps with a little more involvement from frontend folks). I’d like to keep this phase more open for experimentation that seems to benefit us at the outset of design.

Phase 2 of Design

  1. Design takes chosen direction and works through the master page layouts, identifying the columnar grid and content zones. For instance, with this client’s site, there are two master page layouts – the homepage and every other page. On other projects, there are 5-6. The result of this could be the first set of screens we show a client. These are flats as they are now.

  2. Tech builds out these master page layouts in code.

  3. Design continues working on the individual components that go in the master page columns and regions, fleshing out the design system of those components.

  4. Tech builds these components out as they’re finalized in design.

  5. Tech creates pages that represent the designed screens we intent to show the client. Client looks at coded screens during reviews.

  6. Client wants a change to a global element. Design does what is needed to create that if new assets are needed or to iron out any details. Tech updates the global element across all pages (via an include infrastructure). This change is done once and reflected across all pages immediately.

  7. Clients wants a change to a component. Design identifies if the change needs new graphic assets and if the changes impacts any variants of that component. Tech makes updates to these components based on discussions with design. As with global changes, the components are immediately updated across all instances.

  8. Revised coded screens are shown to the client in the next design review.

The goals here are to minimize the amount of time that it takes design to update screens for review, and bring up the start date of frontend coding. Additional outcomes of this are:

  • master pages are coded very early on in the process, allowing everyone to focus on components.

  • components are finished as they are defined; master pages are verified as we continue designing components and adjusted as needed.

  • it is much easier for tech to start soon in a project, lessening the waterfall effect of many of our projects, and shortening the overall project calendar duration (this doesn’t necessarily shorten the project hours).

  • we can show clients more interactive screens during reviews, assisting their understanding of how individual pieces work (powered by real data via APIs or demonstration data we create).

  • it encourages and almost forces cooperation and discussion among UX, design, and tech in a deeper way than we current have on projects. Benefits of this collaboration are: a) designers gain deeper experience of building out design systems for the web; b) tech gets deeper experience building out component systems that are more flexible and extensible; and c) tech and design are working more closely together during each other’s phases, creating opportunities to discuss design/code options at the time they come up. This creates opportunities for designers to gain deeper understanding of the technical elements and developers to gain deeper understanding of the design elements.

Hopefully this would keep project moving, give clients something interactive to review, and further discussions about implementations versus static comps that don’t accurately reflect the aspects of what you’re building.