The Process Behind Wireframing with Developers

Designers work alongside developers, business analysts, product owners, and more, to create digital products. All of these roles need to work together to achieve success. Because of this, we think it’s important to hear from the perspective of non-designers about the role of design in these projects.

We’ve invited an accomplished developer, Nick Barger, to chat with us about his experiences and how he views the role of design when creating something new! Nick is currently the Director of Engineering at KeHE Distributors, leading a team of over 20 engineers in creating new products and maintaining many that are used by over 12,000 employees and customers of KeHE. Previously, Nick was the Chief Technology Officer of the aviation SaaS company Flightdocs where he led the development of new products.

Billy Carlson: Thank you for joining me Nick! Let’s dive into questions.

“What is your product design and development process?”

Nick Barger: It always starts with brainstorming with the entire product team. Low fidelity in the initial stage is key. Collaboration tools that can facilitate this are the lynchpin.

Allowing developers to express their ideas in low fidelity, using quick/easy-to-adopt tools, like Balsamiq, allow complex thoughts to be shared visually and in the same language between all parties (developers, business analysts, designers, stakeholders).

In my past companies, I've set up Balsamiq for developers, design, and our product owner roles. It was the digital representation of "back of the napkin" design. We’d collaborate right in the software. Later, when the general workflow and design structure were starting to take shape, we'd often take a short break and let the designer build out 1-2 of the items in more detail. This allowed us to start to apply and envision the theme and aesthetic style of the product throughout the rest of our Balsamiq low-fidelity designs.

After a few mockups were designed, we would often use a tool like InVision to allow for a lot of commenting and critiquing, adding hotspots to specific design elements we liked or didn't, or just had questions about. We were facilitating the developer/design/business conversation throughout the entire process and not in a waterfall mentality. More Balsamiq wireframes would take place, more and more high-fidelity design work followed, a constant back and forth between everyone… and all was right in the world.

BC: Interesting! Can you tell me more about waterfall and what it means in terms of product development?

NB: In the process that I have laid out, developers don't have to wait for a really long time to begin experimenting or scaffolding. Much of the time we could begin with the structure through the Balsamiq layouts. Later, even if there was rework, it was almost always relatively easy and low investment.

We’d move to pixel-detail development once the high-fidelity work came into place. Usually happened quickly by really strong CSS-skilled frontend developers working from a clean html scaffold. More time could then be spent making sure everything looked proper cross-browser and handling for idiosyncrasies.

When working in the waterfall methodology, we wouldn’t be starting any of that until design has completely finished their work and had it approved. This process allows everyone to begin working on their parts of the project as early as possible. It makes the project move along more efficiently.

“What are some ways designers and developers can complement each other?”

NB: Developers are good at learning rules and applying them. If a designer can help establish the rules (guidelines) then a developer can be good at applying them. That is why design systems are so popular right now. It allows developers to work more quickly. It’s a playbook or box of tools for developers to use.

Also, developers can and will want to build new tools, but in doing so need to partner with designers (who essentially "own" the style/brand) to make sure the new tools mesh with the existing for consistency. Having a set of guidelines allows everyone to be on the same page and to move more quickly when building new products.

“Thoughts on pairing?”

NB: I think it’s great. Lately I've been thinking about this model where instead of having "Frontend developers" and “Designers” on different teams, we have one group (maybe "Frontend Experience") which consists of UI/UX and Frontend developers all working together, with no separation. We all have the same goal and work, and should pair together, working hand-in-hand, all day long to accomplish it.

BC: That is interesting. I have heard of something similar called Extreme Programming.

NB: What if you and I wanted to do some consulting work together? If design and development leaders walk into a discovery meeting together and learn about the problem and/or the goals from the stakeholder, together, then begin to solution together, playing off design and execution in unison, using tools like a whiteboard and Balsamiq (or other visual tools), it will allow us to get concrete ideas (ideas we know we can build) in front of stakeholders much more quickly. Building something that is new and doesn't exist is really hard for people. It's hard to do, but it's hard to ask for as well. Most people know it when they see it, showing is the first step to getting good requirements and direction.

“What should every designer know about the world of development?”

NB: Engineers should be in the same meetings, alongside designers, and product folks, in the early stages of the project, to learn as much about the project as they can. They need the same perspective as the rest of the product team. #nowaterfall

"How do you feel about working in Agile?”

NB: Generally, I like it, but after doing it for several years, I tend to like to take some breaks from the formality of it and just build for a bit together. For managing many sets of teams, I think it's a very nice way to manage a lot of work streams and give teams their own autonomy.

“UX and Design Thinking are hot buzzwords nowadays, how do you feel about this from your perspective?”

NB: I think more people should take a stronger interest and responsibility in the user experience. I think when you're trying to create a solution for someone, you should put that end user at the heart of the solution. I value really highly someone who is in a design role to be both UX and UI. To me, it's synonymous with a developer who is really good at whiteboarding a solution, but can't sit down and code it. There is discovery in the act of coding that is lost when only whiteboarding. I believe UX folks are better when they put their research and advice into practice and validate their findings through the act of design and then further confirm with A/B testing to see how users truly respond (above and beyond what users say/think they like). I'm always looking at what drives user action.

“Where do you think the product development industry is heading?”

NB: I think many more companies are trying to build products internally, but struggle to try and copy what innovative product development companies do. It takes a lot to put together the right culture, talent, and direction to be successful. I do think with better tools, the desire to learn and continuously improve, and experience... individuals and companies will continue to raise the bar for products across all industries, but it takes time and investment.

BC: That is great. Thank you for your time! I am sure our readers appreciate your insights and can learn from your process. Take care Nick.

---

Well that is it! I hope you all enjoyed learning from another talented product creator in our field. Please reach out to us if you have any questions and as always, Happy Designing.

---