I know what to show and what not to show to the user, but the implementation deviates from the intended design. Can anyone suggest to me the solution to this issue?
-
Please elaborate. Who is the user in this case? The business owner, the developer, the designer?– MayoOct 23, 2014 at 16:37
-
There are 5 user groups in this case. Designers, Developers, Reviewers: Who reviews the the design artifacts for quality check, Architects and Project Managers. We need to fulfill everyone's requirements here. We have decided that we will give each user group a different dashboard.– Anurag ChawadeOct 23, 2014 at 16:41
-
You mean the developers deviate from the original wireframes? In terms of functionality or presentation? There are a few questions about this general issue but it really depends on your particular workflow and how your team collaborates.– Matt ObeeOct 23, 2014 at 16:48
-
1No snark intended - but mission creep / making certain that the project is done according to spec (waterfall) or user stories (agile) is the PM's responsibility. That's why he's there - to make certain that things don't go off the rails.– MayoOct 23, 2014 at 16:56
-
@Matt Obee I mean I as an Interaction Designer is getting deviated while I'm trying to implement the features as per the user stories (Agile model). I'm a beginner in IxD.– Anurag ChawadeOct 23, 2014 at 17:00
|
Show 1 more comment
1 Answer
After years in the field as a designer, a design executive, and a PM, at both large and small companies, unfortunately there isn't a single good answer on how to get engineering to build the design as specified. There are a lot of things that can cause this situation, so here are a few scenarios and suggestions.
In essence, this is a problem of failed communication. As a designer, only about half your job is actually designing and planning the system. The other half is communicating your designs to others and getting them to understand and believe in the designs, so they implement them faithfully. They are the users of your design communications, so you have to figure out the right communication tool ('interface') that enables your users (engineers, PMs) to understand your designs.
You also have to be communicating with your PM and engineers to ensure that your designs are realistic and accurately reflect the system that is possible for them to build in the time allocated. ("Oh, we can't build the magical mind-reader by December? Okay, I guess we'll have to use a search box interface, so I'll go design that.") A common thing that I see in young designers (and that I was guilty of!) is going off and redesigning an entire system, or designing in some totally new functionality. The process for that type of design work is different than your everyday, Agile design-an-interface. You have to get strategic buyin for that type of design — you can't really just throw it into a mockup.
- Problem: Engineers may not understand what wireframes are, or how to use them effectively.
Solution: Every time you deliver wireframes, you should have a presentation and walk through them with the team. Answer questions and get their feedback. Ask them what they need more clarity on; invite questions. Revise the wireframes based on their questions and feedback.
Problem: Wireframes are very abstract, and generally, they're hard to use. Static wireframes are extra hard to use.
- Solution 1: Try a different type of design deliverable to communicate your design. Interactive Keynote presentations — where you can record a voiceover as you talk through the design, so the engineers can watch it again — can be very effective.
Solution 2: I know interaction designers hate to hear this, but high-fidelity visual design helps communicate the design to others. Visual design is important. often if you can pair a single high-fidelity design with your wireframes up front, it helps engineers and PMs understand your wireframes better. ("Oh, that big black box in your wireframe is actually where we put the photo!")
Problem: Situations change, features and timelines get changed, and you're not responsive enough, so the engineers just wing it.
Solution: Check in with your team every day. Sit with them if you're not already. Check in with the PM to see what they need.
Problem: All people are inherently lazy. Your wireframes are too hard to find or get to, so engineers / PMs just base things off their memory of your design.
- Solution: Print out the wireframes so people make notes on them and have them at their desks.
- Solution: Use the same issue tracking system the engineers are using — Jira, Pivotal, Asana, whatever. Create tickets with the wireframes, and break down the most important parts into checklists.
Hope that helps! Good luck!
