The Power of Early Design and Development Collaboration
Before we dive into why development should be involved at the beginning of a project’s workflow and not just at the end, let’s take a look at a process that showcases development only being used at the end of a project’s workflow. If we look at the traditional waterfall model, you can see that development isn’t involved until design has done their part.
At face value this might not seem like an issue and in some cases it might be the best methodology to use on a project. My goal isn’t to tell you that one methodology is better than another. There are plenty of well-written blog posts, articles and books on this subject that can do a better job of making a case for using one over another than I can. My goal in this post is to highlight missed opportunities and issues that arise in the development process by doing the traditional waterfall approach.
So let’s start with a simple example of something a developer might get handed from a designer. Using this example, we’ll look at two things. First, what are some issues that can arise in the development process because of the way something was designed? Second, what are some missed opportunities that could have been capitalized on if design and development had collaborated earlier?
Identifying the Issues
In the example above, we have a pretty straightforward section of an ecommerce product page page. From a developer’s perspective, there’s not too much to be concerned about with the exception of one thing. Can you spot what it is?
It’s the custom
<select> field drop down.
If you didn’t guess correctly you might be asking yourself “What’s the big deal with a custom
<select> field drop down?” Well, to start with, something that could’ve taken only a few minutes to style just turned into a four- to eight-hour task since it needs a custom style. The reason being that the drop downs for select fields can’t be styled through CSS or any other way. So to achieve this look we’ll have to convert it into a
<div> with a
<ul> inside of it and behind the scenes pass the value selected into a hidden
<select> drop down which would look something like this…
<div class="custom-select"> <span class="custom-placeholder">Select Size</span> <ul class="custom-options"> <li data-option data-value="34">34</li> <li data-option data-value="36">36</li> <li data-option data-value="38">38</li> </ul> <select class="custom-select"> <option value="" disabled selected>Select Size</option> <option value="34">34</option> <option value="36">36</option> <option value="38">38</option> </select> </div>
Besides that, there are also other issues that arise from this approach. On mobile, the native input select isn’t triggered. So the user will have to scroll inside the custom drop down we create or try to scroll the page itself to see all the options, which isn’t a great user experience. Something else worth noting is that accessibility becomes a concern too with this approach. Since we’re no longer using the actual
<select> field, we have to make sure that the new drop down functions the same way a
<select> field would when using a keyboard to navigate the site and that the proper tagging has been done.
So looking back on this example, you can see that one design choice can make a fairly large footprint when it comes time for development to do their job.
Examining Missed Opportunities
When a developer gets handed a design comp and it doesn’t convey information about animations, how an element will react when a user interacts with, it or how a component should work, issues can arise. Most times, one of three things will happen:
- The developer will code the front end as it is in the design comp and move on.
- Pro: The developer built it as the designer intended (as far as the PSD is considered).
- Con: This is the most common way opportunities are missed. If a design doesn’t convey any information besides the basic styling of a page or component, as developers we should know that this is only half of the story. Meaning when a developer sees something like a search field, he or she should be asking themselves, What happens when a user clicks in the field? Does it have a box-shadow effect on focus? Is there any animation that should be triggered when a user interacts with it?
- The developer takes the initiative and adds “enhancements” to components or elements on the site. Example: Animating a fill effect in the rating stars.
- Pros: This could add a little something that was missing to the site to make it feel more polished.
- Cons: Without having UX or design input on this, the developer could actually be creating a bad user experience or inconsistent styling without knowing it.
- The designer ends up making decisions on how something will be developed with or without knowing it. Going back to how a component should work, when a very sophisticated component has to be designed and it’s done purely off of appearance without taking the technical side into account, it could lead into some difficult problems when it comes time to build. Example: Having a gallery fully designed in the mock-up.
- Pros: Development knows what the designer wants when it comes time to build it.
- Cons: There are a few cons when it comes to this situation. One would be that this could end up being very difficult for development to build, which could affect the scope of the user story or even the whole sprint. Secondly, the designer’s missing out on utilizing the developer’s knowledge. In most cases, a developer can give a designer a list of examples of galleries they can choose from that they know will work for them. Along with that, a developer can also take a designer’s wish list of features and effects and find a solution that satisfies the designer’s wants that is still well thought out and ready for development.
So after looking at a few small examples, we can see some of the pros and cons of development getting a static PSD and not being a voice in the design process.
Wrapping Things Up
Now that we’ve explored some of the challenges that come with development only being involved at the end of a project’s workflow, we can start talking about next steps. The first thing I’d recommend is trying to translate some of these examples into projects you’ve worked on in the past. Once you have a few examples, I’d try to set a meeting with your co-workers or leads to show them the examples I’ve listed above and then tell them the ones you’ve seen on some of your own projects. Hopefully they’ll be ready to talk about how to improve your workflow.
Reevaluating your workflow and coming up with a solution may be the hardest part when it comes to bringing development into the beginning stages of a project. There’s just no one-size-fits-all solution to solving this problem. This is going to come down to your team figuring out what works best for your workflow, how much time to designate to it and when to bring development into the design process. So try to think about how this could integrate into your company’s workflow. Maybe you just have devs in the design reviews before clients see the mock-ups. It might be on a component-by-component basis. I’d just do some reflecting on how your company handles new projects and where you see an opportunity to make improvements. If you’re able to offer a solution to the problem, I’ve found most people are pretty responsive to it and are willing to take what you have and build off of it.