The marriage of design and software implementation has been a positive thing for the user. At Atomic, we receive a lot of good feedback about the use of Human Centered Design, but the design process is really just the start. What brings designs to life is the way our poly-skilled teams work hard to avoid road bumps during implementation, ensuring a quality outcome for our clients.
For successful design and development interactions, it’s important to pay attention to three distinct touchpoints during software implementation.
User Story Definition
After the Research Design and Planning (RDP) stage of the project is complete, the visual designs can be turned into software features. This is the first real test of the team’s communication skills, requiring the design team to effectively get their designs across to the implementation team. There are a number of tools for doing this, including visual design annotation, Zeplin, InVision, HTML prototypes, style guides, detailed messages or tasks in user stories, etc.
Ideally, the team will sit together to review the proposed designs. Often, this meeting is the first time developers will see a particular feature, although the designer may have been working on it for weeks. That’s why it may be useful for the designer to start the conversation with an elementary overview.
I like to use this time to bounce concepts off the implementation team, especially if I’m looking for more efficient ways to accomplish a task. The team can potentially save the client a significant amount of money by altering designs, but it’s important to balance usability, user delight, and costs.
Finally, the implementation team needs to feel confident that they can implement the designs, building on the details held within the user story (or assets linked within).
Communication During Feature Implementation
Before the implementation team tackles a new user story, it’s a good idea to have the developer and designer sit down for a quick review of the story. It’s likely that neither party has engaged in the details of that feature for some time, so it can be a good refresher. Review the visual design needs, and make sure to identify any interactions or animations. This is the designer’s last chance to communicate their desires for a feature before re-work on the story is necessary.
Developers, don’t hesitate to ask if you’re not sure of something. Designers can be like bloodhounds on the hunt as they can pick out seemingly minor deviations from their designs. So, it’s better and less expensive to implement the design correctly the first time.
Feature Review
Once a user story has been implemented into a software feature, it’s typically ready for the project lead to accept. Despite all the efforts toward continuity, there’s inevitably a feature that deviates from the designer’s expectations. These deviations range from small color changes to larger issues like the way the sort feature is returning results.
Asking the designer to join the project lead in user story acceptance is a strong strategy to help identify and triage these issues. Another path to success is adding a checkpoint before the final sign-off where the designer can review the features before presenting the work to the project lead.
If a newly developed feature does need additional work, the question of how to spend resources can be answered more equitably. This gives the designer, and thus the user, a stronger voice in the process, instead of allowing the pressures of dollar savings and time crunches to erode the impact of good design.