4

In trying to understand the UX Process, I was wondering how do you know when your design (which has been prototyped and tested) is finally ready to go to the coders for development?

Also, after the coders give you the "finished" product - does it go back into testing again to validate your design approach?

4

This can be a tough question for a variety of reasons and depends upon factors such as experience/quality of the designers, experience/quality of developer, and communication.

As a developer and a designer I've been on both ends of the spectrum. From a developer's standpoint, I have a project manager who comes to me with a user story that is based on a new design. The design then has to be broken down into features, and those features are broken down even further into "tasks" that can be distributed to developers to begin actual coding.

Communication is vital throughout the entire process. If the developers were cued into what was happening during the design and prototyping process, then you should have already avoided some possible points of friction.

You should never really consider your product "finished". All software is continually evolving and is done through the input of all stakeholders involved. A product can - and will - go through testing and come back for changes over and over again. This is part of the iterative process and this is why it's so important for developers and designers to work closely from the beginning.

If a designer works in a vacuum and presents a couple of weeks of work to developers without any communication in between, then you may have wasted time designing a component that already exists in the developers toolset or you may have designed something outside of the capabilities of the developers (remember the quality/experience factor).

Ideally there will be a lot of back and forth throughout the whole design phase. If you are in an organization that likes for departments to work separately, then I would push to have more communication and transparency because that would make everyone's life a lot easier.

  • 2
    Hey @PhillipKregg - thank you for the wonderful reminder not just to throw designs "over the wall" to the developers but to incorporate them in the process all the way through! – Steve Crow Apr 30 '16 at 20:58
  • 1
    Not just easier. Also a lot more efficient and more importantly: more effective. +1 – Marjan Venema May 3 '16 at 10:41
3

When all stakeholders have signed off

There isn't really a definite answer for this, but the coverall answer is "when all stakeholders are satisfied with whatever part of the system you're working on". (I say this because, depending on your working methods, stakeholders might be signing off on whole sections of a product, or individual components)

That usually means something like:

  • Product managers agree that all functional requirements are met
  • Designers agree that screens and interactions are sufficiently polished
  • Developers agree that the requirement have been sufficiently specified

(who qualifies as a stakeholder depends on the project and org structure)

In an ideal case, and in your case it seems, this list should include:

  • Screens/interactions have been user tested (and feeback implemented)

In most cases, however, this last one doesn't really happen.

does it go back into testing again to validate your design?

It depends on how much difference there is between what you last tested and what the developers build.

e.g. if you last tested with low-res wireframes (to validate major design decisions but not interactions) and from there created high-res mockups and designed interactions that developers are going to build, you should test again before releasing.

If you last tested high-res prototypes that had working interactions, and the developers are simply going to replicate this, there's much less pressure to test again.

Re: testing a "finished" product i.e. something that is in production. If you're doing things right, everything in production should be sufficiently tested. Assuming that is the case, once something is in the wild, it's usually not worth retesting unless required, perhaps for one of the following reasons:

  • a specific conversion process is under-performing
  • users report issue with a process (through support tickets, or direct contact)
  • Element(s) trigger a lot of error codes
  • Thank you @dennislees , that is a very complete, clear and helpful answer - thank you very very much! – Also, would it be okay to share your answer on the UX Mastery Community page and on Slack's UX Design Community? I think a lot of other people could benefit from what you've shared here! – Steve Crow Apr 30 '16 at 20:57
  • 1
    Thanks @SteveCrow though I imagine there are many alternative takes, and the last point about testing in production is open for debate. By accepting this as the "right" answer, as you have done, you make it seem like more of a done deal than it actually is. I don't mind taking the points ; ) but I suggest that deselecting this as the accepted answer might see it get more attention and more input. If you want to show your approval for an answer early on, you can simply upvote it. – dennislees Apr 30 '16 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.