Bridging the designer-developer divide

The relationship between designers and developers can be fraught and contentious for reasons too numerous and complex to list here (but like most designers, I’ve got a curated and up-to-date enumeration of these issues in my head). While there may be an element of the Discovery Channel “lions vs. hyenas” struggle at play here, a lot of the friction arises from poor communication.

The fault lies on both sides. Developers often expect more detailed specs and instructions than designers think are warranted, while designers regularly overestimate how much devs can be expected to interpret and read between the lines of loosely defined hand-offs.

Prototyping can help defuse this tension. Even a rough will allow development to point out potential problems and feasibility issues: we can’t do that on this platform; we’d need too much time to build that; that would require expensive third-party solutions that would break the budget. Identifying such issues early on will save time and tears down the road.

Working closely with developers early in the process helps to identify potential failure points in a concept flow, as well as opportunities and solutions that enhance the product. In my experience, this tandem effort has always yielded critical insight as part of what is still widely classified as the design phase. Recently, I shared a prototype demonstrating new functionality for an app I was working on. It just wasn’t hitting where I wanted it to, so I ran it by a favorite dev, whose instincts I trust completely. “We can do all this,” he said thoughtfully, “but there’s a couple of APIs that would be even better here and here.” Successful products require this type of collaboration in their early stages, which is now much easier to facilitate with prototyping before actual development begins.

A few common myths about prototyping

I don’t know the first thing about prototyping

Not to be argumentative, but actually, yes, you do. It’s integral to every kind of design, although we might call it by different names: concepting, iterating, mocking up, etc. Imagine you’re designing something non-interactive, like an ad or a poster. At some point, you need to put something in front of whoever requested the design to get their thoughts.

It won’t be the final product because you want input before putting in too much potentially wasted work, so the images might be for placement only, along with the body text. But the critical aspects will be captured: typeface, palette, general layout, and relative dimensions — enough to communicate where you’re headed so you can get meaningful feedback and shift your direction as necessary.

That’s a prototype. It only differs from a prototype in that the latter is interactive, because that’s one of the aspects you need to communicate for that kind of design. But the same thinking that lies behind your poster mock-ups or ad concepts informs building a prototype. And the goals are identical: learning enough, early enough, to correct the course and save time and trouble down the road. You’ve been prototyping all along.

Prototypes are hard to build

I won’t lie: many prototyping tools demand a real investment of time and effort to master, and if you’re part of the gig economy, it’s likely you’ll be asked to use many of them. Yet a lot of the hardcore packages are most appropriate for building data-driven simulations that blur the line between prototype and final code.

Fortunately, there are now many alternatives for code-adverse creatives (like yours truly). These lightweight tools are much easier to learn and generally draw on patterns and approaches you’ll recognize from other software that should be familiar to most designers. Match the tool to the job and push back if you’re asked to use the equivalent of a sous vide cooker to make instant ramen.

Prototypes are too time-consuming and a waste of precious time

As noted above, contemporary designer-friendly prototyping tools recognize that we’re all working under often unreasonable time constraints. So while you may have had bad experiences in the past, I’d urge you to check out the newer options and see if you still encounter the same problems. If you choose the right tool, it shouldn’t require an unreasonable amount of time to build a prototype.

Realistically, some factors can extend your build time. If this is the first or second prototype you’ve built using a particular tool, it’s going to take a little longer than later efforts. But that extra initial time is an investment that will pay dividends in shorter build times down the road.

A complex interface is also going to require extra time for prototyping, both in minutes spent in its construction and in identifying new components and interactions necessary to render it faithfully. But complicated designs should usually have more generous overall timelines, which can better accommodate time set aside for prototyping.

Finally, don’t think of prototyping time as a simple addition to your project’s timeline. This is time that can often be made up down the road, by avoiding additional design cycles to win stakeholder sign-off or by front-loading what you’ll need to hand off to developers. Depending on the tool you employ, there may also be opportunities to shift some of the specification work downstream.

My project isn’t a good fit for a prototype

You’re likely wrong. Yes, there are instances when a project schedule simply doesn’t allow room for building a prototype or for making timely use of feedback from its presentation. And I suppose there may be interfaces so simple and straightforward that a prototype would add nothing of value. But generally, this is a tool that’s both applicable and helpful for the majority of UX designs.

I’m not the proscriptive guy that will tell you you’re a careless designer because you haven’t made room for a prototype in your process. If I’ve anything over the years, it’s that there are no absolutes in design, and when all is said and done, trust the judgment of whoever is on the ground. But I do think that you should push yourself to see if prototyping might aid your process.

And finally some words of advice

Find the right level

Don’t go overboard. You’re not building the final app (or even the final design), so try to stay focused on your goals for the prototype. What do you want to demonstrate? What needs more explanation? What is superfluous? It’s all too easy to get lost down the rabbit hole of “this isn’t precisely right” when the whole point of the prototype is to figure out what is right in the first place.

Trying to capture every possible user path or flow at the early stages can be a thankless and self-defeating exercise. Focus on the core user journeys first, building out the bones of the app or experience, and then go back in and progressively add layers of detail as the project progresses. That way, you won’t have to untangle everything as shifts in hierarchies or flows happen.

Source link


Please enter your comment!
Please enter your name here