Recently, four representatives of the Perficient Digital development and design teams got together to discuss the relationship that exists between the development and designing portions of work that is produced here at Perficient Digital. Participants in the discussion included designers Andrew Hainen and Mike McGowan, as well as developers Mike Behnke and Karen Ford. The discussion was kicked off with two major questions:
How does a designer having experience with HTML/CSS, or other front end web technologies, influence their design process?
To answer question one, Andrew explained that a lot of times when designing websites, he thinks, “’oh that would be really cool,’” but the design can’t be accomplished technically, so [he] won’t even explore that idea.” He continued to express that this limiting of ideas could be inhibiting as designers may be scaling down their design preemptively due to assumptions that the design wouldn’t be technically viable. In response to this, Mike B. jumped in, explaining, “The knowledge you have of browsers and of CSS could potentially limit your willingness to express bold ideas, as you might assume that they cannot be achieved based on what you already know.” Stemming off from Mike’s comment, Karen added, “Some knowledge is more dangerous than no knowledge. With no knowledge, you’ll try it, and then wait for someone to tell you whether or not it’s possible.” It seems as though one’s own perceived limitations are a major problem when it comes to creating bold and innovative work.
From this stems additional room for inquiry, however. Andrew wondered, “Is it the case that having an understanding of the way browsers and CSS work will be completely beneficial for every project?” The idea as to whether or not a designer having an extensive familiarity with browser possibilities and limitations may actually provide developers with successful work. Andrew continued, “The opposite case being a designer creating something more bold and explorative, but not technologically feasible.”
To add, Mike M. reflected on his own experience in learning the development side of design. He explained his involvement in an HTML class, expressing that throughout the program, he is “getting more and more sensitive to it as I go.” He added, however, that he “can see that in [his] mind, trying to understand the little sandbox [he is] supposed to be in is very small, but it should be bigger as [he] gets more education.” According to Mike M., it’s rare that his ideas are impossible to achieve, rather he just is unaware as to how to bring them to life. Mike B. insisted that it is not necessarily unhelpful for a designer to have limited knowledge of CSS/HTML functions, but with limited levels of knowledge, there exists a separation in the designer’s mind between “what designs are realistic and what designs are ideal.” This separation can, but does not have to, restrict quality of design. Mike B. continued by calling attention to the fact that designs produced with little understanding of how they will be developed “might actually be in its more ideal state, even if it’s not ‘efficient’.” Andrew added that he wondered where many of his own projects would have wound up had he not had prior knowledge of development processes – would they have been better, worse, or just different?
Mike Behnke explained, “from the developer’s point of view, it’s nice when there’s that knowledge there.” He described an example where in a designer fleshed out a website’s header and body design, “but also [accounted] for the design outside of that area,” citing details like, “how the background will tile, and how the design will respond to various window sizes.” According to Mike Behnke, “it’s good for everyone to know the limitations of the design.”
Karen expressed her take on the situation a bit differently: “there are some things that are great for designers to have a basic knowledge of,” she said, “but at the same time, I’d prefer them to not have a real specific knowledge, do something really cool, and show it to me.” According to Karen, if the design is too lofty a project, she could simply say, “’I don’t know how to do this’,” but eventually figure it out and make it cooler.” Karen feels that this trial and error process can be more effective than “sticking to what you know can be done technically,” because without pushing the envelope, innovation is difficult to achieve.
Stemming from this question, Designer Mike M. posed an important question: “Does the knowledge a designer have to cut off the collaboration between a designer and an engineer?”
In response, Karen explained the complexities of the situation from her perspective: “It could, if the designer feels as though they know what they’re doing so much that they don’t need the developer.” She continued by citing an example from her own working experience: “Some of the projects I’ve been the happiest with were the ones that the designer was constantly asking for continual feedback about how a design would work technically. It’s good to make prototypes, to keep pushing the design towards something else. Maybe the answer is, ‘no, this can’t be done,’ but it forces you to keep trying – you can’t assume that everything can’t be done just because it hasn’t been done before.”
While all of this is true, it is also important for designers to be confident in their own work. According to Mike B, “[designers] can’t assume that the developer won’t be able to figure out how to make their design come to life. They must have enough confidence to assert that they like their idea, and insist that the developer figure out a way to make it happen. “ While this kind of pushback can oftentimes be frustrating for both the designer and developer, the pressure applied forces some of the best work to come to life. Karen explained, “Sometimes budget or time constraints require developers to say, ‘I’m sorry, no, this needs to be adjusted.’” However, this pushing rendered her “able to continue pressing forward to learn new methods to make ambitious design a reality.” It is likely that incidents such as these can set a precedent for designers, teaching them that this type of pushback is not only helpful to their own progression, but also to the progression of the creative process, as well.
The discussion continues, read Part II here.
