
Changes to Developer Specs
This is an ever-evolving remote project that involves creating interactive specs from Adobe XD that are easier for Lumen.com developers to view and understand our proposed asset functions.
My Role
Remote UX / UI Designer,
Wireframing & Prototyping
Project Duration
Average 1 month per dev spec
Area of Focus
Visual Communication, Functional Specifications, Web Development
Synopsis
In order to help the developers know exactly how the new web modules function and are designed, I helped popularize the formula of adding more visuals, like storyboarding and videos, to make it easier for them to understand the functions of the web module.
If you want to jump ahead to view the background, different iterations, or final design, you can click on their respective links below, which will take you straight to that process.
1. Challenge
2. Inspirations
3. Iterations
4. Recent Design
Challenges & Restrictions
Despite being an internal projects that involve only the creative and developer team, there are still technical limitations when creating the specs.

Adobe XD Prototype Features
Have to submit both functional and visual specs to the developers, more room for outdated errors

Everchanging request on features
Have also updated and changed the spec to reflect recent changes due to developer requests or overlooked features.
The Developers Concern's
-
Not enough visuals to tell how the asset works.
-
Constantly have to recheck with the UX team.
-
Swamped with additional work.


How might we improve our developer specifications so that we can easily communicate with the development team on how we want the asset to be built.
Inspiration
Proposed Features
Iteration 1
The Feedback
After delivering the dev specs, I requested feedback from the developers in order to see what I can improve on.

Too many links that we have to follow
Sometimes we get the wrong link, or the dev spec link is for another module.

Hard time following complicated modules
Especially when the modules have multiple functions and conditions.

Some of these pages are very long
Like the ones that showcase mobile and tablet.
The Changes
Additional changes made
Indicating where, in the screen, the user is clicking
Show where the user is interacting so that the developers can easily follow the storyboards.
A link to the visual design specs
So that the users can switch between specs rather than having to go and find each link.
Actual interactions that the devs can interact with
Have the developers play around with the module itself so that they can use the module in real time.
More detailed showcasing of responsive design
Includes screenshots that show how each module changes from desktop, small desktop, tablet, and mobile.
The impact
These feedbacks were obtained after going through several more rounds of developer specs.

"The videos greatly helped us."
"It gives us an easy reference to build the modules."

"I can spend more time building it."
"I don't have a lot of questions after seeing this."

"It makes it easier for designers to follow."
"Can be used as a reference for future developer specs."

“Its almost like giving the developers a cheat sheet with how detailed the specs are.”
Visual Designer / Developer
What I learned:
Show the stats of the modules
Easy for the developers to follow, especially when it comes to building a complicated module.
Visuals and videos can carry more information
Wireframes can still be mistaken for the final design
Like testers, if you give them the functional specs using the final design comp of the module, it will cause the developers confusion if the design changes.
As it has helped our developers out a lot, since they now have an exact reference, decreasing the number of times they have to visually check with the designers.
What I can improve:
More indicators that this is not a visual design spec
Developers still have a hard time discerning the functional spec as UX UX-specific spec instead of a visual design spec.
Maintain collaboration with visual designers
Since there can be specific specifications that the visual design spec might have that would confuse the developers of the functional spec doesn't.
Remain low-fi wireframes to avoid last-minute redo
Since visual designs keep changing, we want to avoid having to replace all the images and videos again.
Have everyone be on board with the design before making the spec.
To avoid constantly changing the spec and also having the spec be out of date, simply due to last-minute changes.