what designers can learn from developers

What Designers Can Learn from Developers

Posted in General1 year ago • Written by Tuts Staff
No Comments

In many ways, it’s not a big surprise that the agile software development process has swept the tech world off of its feet. With both the pace of business and client expectations growing at an outsized rate, older systems like the waterfall method seem downright Titanic in contrast, lumbering blindly into a sea littered with icebergs.

But, as many designers know all too well, the agile process isn’t a template into which the design process can be simply dropped. Doing so can create a number of problems for designers, putting them at risk for developing design tunnel vision and losing track of the greater whole. Instead, it’s much better to use the agile development process as a metaphor that can be adapted to a design team’s specific purpose. Here are a few concrete ways to do just that.

Code stock photo by Bigstock

1. Continuous Integration

How it Appears in the Development World

In the development world, integration is a process in which members within and across development teams quite literally integrate their work into one block of code to see how it runs and test it for bugs. In the waterfall method, integration is completed at various checkpoints along the way, with weeks if not months in between each one. This leads to very tense periods as teams hope they’ve been going down the right path; it also leads to a lot of backtracking as bugs are found and retraced to their roots, requiring work is undone and rebuilt.

In contrast, continuous integration, the method used in agile, is, well, continuous. Integration occurs on a daily not weekly or monthly basis, allowing devs to catch bugs early and fix things as they go. This clears out space for devs to concentrate on creating new and interesting features, rather than backtracking and doing double the work as they rebuild.

How to Apply This to the Design Process

The agile process holds much more in common with the theory of emergence than more top down organizational systems. While designers will never do continuous integration per se, the basic idea of consistently incorporating the work of a wider team into one body can help a project evolve without becoming too disjointed. This can be accomplished through intense design scrums and sprints that unite team members around common goals and promote communication.

It can also be helpful to implement frequent design spikes in which the team can pull back to the more holistic level to consider their work at large. This will both bring clarity to the work and help designers embrace agility without losing sight of the whole.

2. Use a Problem Solving Point of View

How it Appears in the Development World

The waterfall system necessitates a long, initial period of research that enables devs to identify all the issues at hand and create a game plan for the entire process to come. While there is of course a larger picture in the agile process, an emphasis is put on just jumping in to create working products from day 1 and solve problems on a smaller scale as they arise. In this sense, problems aren’t so much problems as they are relevant data to guide the shape of the development process, and many times even the project’s final goals. This again fits with the ideas both of emergence and agility, as order and structure bubble up organically as each problem is resolved. It also fits in nicely with the testing mentality discussed below, as it provides both the customer and development team with a steady stream of products with which to engage and tweak.

Also, it should be noted from a management and motivation level, breaking large issues into smaller problems make them much more likely to be addressed, rather than overwhelming and paralyzing those who have to resolve them.

How to Apply This to the Design Process

Creativity can (and in many cases, should) arise from problem solving. In fact, it can be helpful to view problems as constraints or parameters that guide the shape of the project, much like, for example, the fake TV news format of The Daily Show informs just what it is the show’s writers can do. In this way, problems that arise within the design process can be just like a dev’s data, forcing designers to think creatively within given bounds, all without losing site of the project’s ultimate goal: to be operational.

3. Get a Good Idea of “What’s Possible”

How it Appears in the Development World

Another big issue with the waterfall method is that, though plans may be based on real world research, they’re mostly made in the abstract. In contrast, one of the basic themes of agile is “always be testing,” an idea that in practice helps devs gain a consistent sense of just how their code is performing in real world conditions and readjust. Frequent testing allows devs to think creatively without losing track of the deeper picture.

How to Apply This to the Design Process

Frequent tests are a crucial way to ensure even the most creative work is still functioning in the way it should. One great way to do this is to work in browser rather than mocking up big PSD files before the launch of a product. This way, you’ll be creating work within the actual environment in which your designs will live. This should significantly decrease the number of surprises as a design is made live down the road.

What’s more, it’s important to stay in frequent communication with devs about just what will work well, so you can create designs that are actually possible to implement.

4. Constantly Communicate With Your Customers and Your Team

How it Appears in the Development World

In the waterfall method, long periods of time elapse between initial client-facing meetings and the presentation of work at infrequent benchmarks. In the agile process, on the other hand, constant communication both between and among customers and team members is essential. This is the missing piece underlying most of the points articulated here; communication is what enables devs to present working minimal viable products (MVPs), have the customers test them in a real environment, and readjust based on their feedback. It’s also pretty much the only way a team can perform under such intense and rapid conditions, checking in at daily scrums.

How to Apply This to the Design Process

Likewise, frequent communication keeps designers grounded in the realities of a process, while also providing rubber stamps for new and developing creative visions. This is especially true if you work in browser, as the client can gain a much better sense of what a site will actually look like as it comes together, providing feedback along the way.


Taken together, agile design is simply an application of the agile methodology to the design process, with crucial tweaks along the way. As in agile development, communicating well, communicating often, building well and shipping often will have a wide range of benefits for designers at large.