Design Process: 7) Validate Ideas with Tech, Dev and Content staff
Any designer can sit down and create a page. But asking them to do that without proper context is a terrible idea. They need the proper input from the folks whose job it is to collect or decide that information.
Common questions are:
Technology: What technology will the site utilize? What are the possibilities and limitations?
Development: What programming language will be utilized? What is the front end framework that will be used?
Content: What are the main messages that need to be conveyed to the user? What types of content will there be, and what categories of them will you have?
Typically this takes the form of several different documents and a series of sketches.
Once those are understood, the designer can then check these boxes off of their list as they validate and verify the wireframes of the site.
Expect the site design and build to take longer than than you think it should in this step. This is where you will change the scope, and change the direction of the user experience of the application or website you are working on. It’s fairly common, as you generally think about things that you could or should do as a user at this point. It’s imperative to get the flow of the site or the idea of a design right in this phase, as you can change fairly easily and not affect the work of others and waste time and money.
Make sure each person responsible for their portion of the solution signs-off on the design. It is important that you have validation that they saw it and agree with what is proposed, as problems could arise later on if this step is not completed.
Potential Pitfalls
Creators sometimes can get too ambitious. They can propose things that aren’t easily developed or add features that weren’t part of the scope.
Having documentations or discussions before the design is ready to be socialized is always a good idea. You don’t want the designers to propose ideas that can’t be built or add a lot of time to the project for a new feature that was not discussed.
Not validating ideas is a sure fire way to build animosity between the designer and developers, and makes promises that can’t necessarily be kept, leading to tight deadlines and ultimately poor execution by someone during the process.