MONOSUS
ICECREAMING MAG

We have investigated and carefully examined the changes occurring in Coding Factory's production site.

Hello. This is Kojima from Coding Factory (hereafter referred to as CF).

Over the past two years or so, the world of CF production has changed considerably. However, I've recently begun to feel a slight disconnect between the "changes in the situation" and the "perception of them," which has been bothering me. In order to discover the true nature of this feeling of unease, I have tried to identify and consider what specific changes have occurred.

The feeling that simply enriching your input is not enough

In July and August of last year, I held a seminar titled "What is really needed on-site for fast and accurate web production?" At the seminar, I said, "The environment surrounding web production sites has changed rapidly in recent years, and as the content of production has become more diverse, it has become more specialised, and roles have become more segmented and specialised, making production more complex."

Specifically, I mentioned "changes in production content," "changes in the development environment," "changes in the production system," and "changes in the production flow," and suggested that it is important to properly relay output at each process so that the requirements you want to achieve in the plan (output from the upstream process) and the information required for implementation (input from the downstream process) are correctly linked, and that since the output from all processes is consolidated in the front-end process, if you identify the inputs required for this process, you will be able to cover all the materials and information required for production. With this in mind, I proposed an input sheet (a sort of chart that covers all the specifications that need to be confirmed, etc.).

I thought that if we could follow the items on the input sheet to confirm specifications that are easily overlooked and align our understanding, everyone would be able to proceed with production without any confusion, and we could avoid fatal problems arising later.

At CF, the production team uses this sheet from the beginning of the project. We have also received positive feedback from seminar participants who have adapted the sheet to suit their own company.

I thought that "No matter what, input is the key," and I thought that this would solve about 80% of the problems, but there were still many unexpected production times and adjustments that needed to be made, and I was left feeling frustrated.

The frustration of the calculated man-hours and budget/actual man-hours not matching continues.

Around the same time as the confusion over input, we began to see a number of cases where the estimated labor hours in the initial quote (rough estimate) did not match the customer's budget, and cases where the initial quote did not match the actual labor hours once production had actually begun.
Despite increasing the level of detail in our interviews, why was there such a large discrepancy between our initial expectations and the actual outcome? Why was our understanding not aligned with that of the customer? This left me with a growing sense of unease.

Identifying and examining changes in the production site
Comparing the changes from the early days of responsive design (RWD) to the present

These issues (feelings) were brought up as topics at the monthly meeting of the five departments responsible for CF services, and we discussed why this was happening, what we should do, and so on. We decided to start by trying to simply identify what specific changes had occurred on the production front.

So, I tried to identify the differences between two periods: the early days of responsive (RWD) production (2014-2016) and the present (2017-2018).

Early days of responsive design (2014-2016) Present (2017-2018) category Approximate additional work hours
01 When switching between SP and PC, it was sufficient to guarantee only the behavior when reloading. Many sites use a liquid layout, which means that the layout on the SP and PC do not change when the browser is resized. specification 1 hour ~
02 In the case of SP and PC RWD, tablet compatibility was not generally implemented. Even in the case of RWD between SP and PC, it is generally recognized that the PC layout will fit on the tablet. specification 2h
03 The client was also searching for a design that could be handled by RWD, so there were no projects with complex layouts. As browsers support more CSS and JS and UI/UX has matured, it has become possible to create complex layouts. design 1.2x
04 There was little implementation of animation or parallax (parallax effect). It is common for parts to have animations and parallax effects implemented. design 2 hours ~
05 Use text images for fonts that may not be available in the user's environment.
Font sizes are often specified in pixels or percentages.
Web fonts are often implemented. Generally, text is implemented using device fonts.
There are also an increasing number of specifications such as vw that change the font size to match the width of the viewport.
font 1.2x
06 There is no SVG support for logos etc. Logos are generally SVG compatible. image 0.5h
07 Basic text is written horizontally. Sometimes there is a vertical layout. font 2 hours ~
08 Most submissions are in Photoshop or Illustrator. Illustrator files are converted to PSD.
Sometimes there are Fireworks (PNG).
In addition to the above, we have seen an increase in submissions in Sketch and XD. tool 1.2x (learning costs when introducing new tools)
09 Task runners, preprocessors, and template engines are generally not used. I mainly use gulp, Sass, and git for my work. I occasionally work on projects that use EJS and pug.
We sometimes take over a client's production environment.
tool 1 person-day and up
10 Coding guidelines often use the CF guidelines. CSS design and unique guidelines such as BEM, FLOCCS, SMACCS, and OOCSS are often specified. specification 1 person-day and up
11 Only the SP was compatible with high resolution (Retina). As PC LCDs become higher resolution, there are cases where PCs are required to support higher resolution as well. specification 1.2x
12 There is little accessibility support. Accessibility conformance levels A, AA, and AAA may be required. specification 2x
13 There is little support for OGP tags. I am often asked to support OGP tags. specification 0.5 hours ~
14 From submission to delivery, the basic production flow (mainly waterfall) does not deviate significantly. From submission to delivery, the production flow often does not proceed as expected.
The production flow varies greatly from project to project.
specification 1.5x
15 The specifications and design are largely finalized by the time markup begins. There are also cases where the specifications are not finalized and the design is produced after a prototype is created. specification 2x or more

What emerged from the washout
After examining each item, three points became apparent:

(1) The large number of variables (mainly tools and specifications) and changes in the process leading up to implementation

Websites are no longer just for disseminating information, but have come to have a wide variety of functions and scales. As a result, specifications have become more diverse, and many tools have appeared to suit the development content. In this environment, in order to select the optimal tool for individual site production and to formulate the specifications, it is important not only to have technical knowledge and skills, but also to understand the needs of what you want to create and what you want to achieve, and to communicate with the technical direction that combines, proposes, and adjusts the optimal configuration from among many possibilities, and a lot of work is actually allocated to responding to this.

(2) Changes in design reproduction and adjustment

With the spread of CSS3 and web fonts, the range of designs that can be reproduced using CSS rather than image extraction has expanded. In addition, with the maturation of UI/UX, the number of screens with complex RWD layouts has increased.
This has led to detailed adjustments using CSS, which has increased production man-hours by about 20% compared to the early days of RWD. Also, CSS production now requires high levels of skill.

(3) Changes in production flow due to an increase in things that are difficult to keep up with just the design and specifications

As in (2), in addition to static displays, designs are now being developed to implement motion and interactive functions, and to optimize displays for various screen widths and devices. It can be difficult to convey an accurate image of the movement of motion in designs and specifications, and the specifications for function implementation and optimized display depending on screen width are becoming more complex, so it is necessary to adjust them while creating the product to match the image the customer has in mind. Also, when you actually test the display of what you have created on various screen widths and conditions, you find that there are small details where the specifications have not been fully worked out and that there are problems. You can improve the quality of the product by adjusting each of these.

In addition, rather than the waterfall-style production flow seen up until the early stages of RWD (where specifications are solidified in the upstream process and implementation on-site proceeds according to those specifications), a build-up style production process is becoming mainstream, in which the basic specifications are finalized upstream, but the details are solidified as they are created and refined.
In the production field, it goes without saying that high front-end skills are now required compared to the early days of RWD, but it also seems that technical direction skills and communication skills to move production forward while making proposals and adjustments are now necessary (or perhaps we could even say essential).
We also found that not only were the man-hours for actual production increasing, but also the man-hours for verification and communication, and that in terms of the schedule it was taking longer to complete.

The answer to the vague feeling

At this point, I finally began to see the true nature of two of the things that were bothering me.

First, while roles are being specialised and subdivided, requiring expertise, in order to make optimal proposals and adjust implementation, it is necessary to have a bird's-eye view of the overall project, not just information about one's own specialized field.

Another problem is that while a lot of communication is required to coordinate with related sections that have been divided and subdivided, the skills and effort required for this are difficult to evaluate. In other words, it is easy to recognize how difficult something is, but not how easy it is.

At this point, I realized that the content of production has become more complex and diverse, and roles have become more subdivided, specialized, and specialized.

  • Deepening expertise = enhancing the vertical axis
  • Getting a bird's-eye view of the entire project = understanding the horizontal axis and areas
  • Communication = the ability to connect and bring together the vertical and horizontal axes

I believe that these three elements are very important, and the better you can balance them, the faster, more accurate, and more efficient the web production will be that best suits your needs.

Although the punchline is a little surprising, it makes me think that the answer is actually quite simple. With these three elements and their balance in mind, I would like to review and adjust things like "visualization of labor hours," "service structure," and "skills improvement education," etc.

KOJIMA Izumi