Please enter a valid email address.
THANK YOU. Please check your inbox for a confirmation email.
X
When is the Best Time to Define Design Requirements?
Posted By : Gary Galvin Posted On : October 25th, 2011
Topics : Design, Interface Design, User Experience Design
Whether you are developing a website or a software application the user interface design has to be remarkable. But between the various deliverables of a project what is the ideal point for defining the design requirements start?
Design is the most important part of any website or software project because it’ll impact the user experience. Don’t get me wrong, without the database, the software code, the testing and everything else “under the hood” the application won’t work so I don’t want to give the impression that those aren’t important because they are. But it’s the user interface design that allows a user to interact with all that functionality and put it to work.
But does functionality drive design or does design drive functionality? Ultimately, they need to come together at the same time. We have taken on development projects and the designs for the user interface were already complete but the functional requirements have not even been defined yet. We have also taken on design projects where everything has been developed but nothing has been designed yet. These have each created obstacles and some rework.
The ideal situation is to make it a collaborative effort. Design teams and development teams have to work in unison and the best way to do that is to get all sides engaged from the very beginning. When the functional requirements are being defined you would want the development team and the design team discussing how each requirement will function as it relates to the overall experience while being mindful of the budget. Once the functionality has been defined then both developers and designers go into their corners and work on their next deliverables while the business analyst starts writing the use cases (or user stories) for those requirements. The user interface designers now know how the application will be architected and what the solution needs to be so they are able to take those requirements and start creating the wireframes. Each wireframe will be designed so the functional requirements can be met. After all this is complete then the beauty starts by creating the graphical design which now matches the wireframes which matches the functional requirements.
Other Blog Posts You Might Find Interesting
Comments
Share Entry
2 comments on this post
Add a comment
Comments
Comments RSS
Jon Speer
Funny, I wrote a post on a very similar topic (“What Comes First: Design Input Requirements or Prototype?“) on 10/24. My inspiration was streamlining medical device product development. While you insights are clearly software development related, there are clearly parallels. And I think this is VERY important for product developers to realize. It’s less about the product and more about the process. I’m biased of course: I love processes and describe myself as a systems guy.
Keep up the good work!
Gary Galvin
Jon,
I read your blog post titled “”What Comes First: Design Input Requirements or Prototype?” the night before I wrote this post and it gave me a bit of inspiration on the topic. Over the past couple years you and I both have commented on the similarities between our production processes and how important it is to follow systems to get to the end result. In your blog post you mention the prototype as a stage to get the product into the hands of testers and get them trying it before the design has even started. I’m a big believer in this because, just like in software development, if you don’t get the requirements nailed down first then you’re simply wasting money on rework.
Thanks for your comment and keep up the good work in the medical device world.