When should you create a functional requirements document for a website redesign project? Are there instances where an FRD would inform the wireframes? I'm used to functional requirements being written after wireframes are created and approved but I recently had someone mention the opposite. Doesn't it make sense for the wireframes to inform functional requirements instead of the other way around?
55.1k 22 22 gold badges 141 141 silver badges 243 243 bronze badges asked Sep 5, 2012 at 20:29 Sree Bhandaram Sree Bhandaram 313 1 1 gold badge 2 2 silver badges 6 6 bronze badgesI am really looking forward to a comprehensive answer to this one, preferably backed by industry experience and examples
Commented Sep 6, 2012 at 1:52 How would you know what to put in the wire frames without knowing what functions are required? Commented Sep 6, 2012 at 5:57Marjan - As Justin replied below, the term 'Functional Requirements' is quite ambiguous and I was referring to a Functional Requirements Document that is typically created to ensure that internal teams like UX, Design, Development are all on the same page about the functionality the website. Before we start the wireframing phase, we conducted a lot of user research that identifies the functions or features for different sections of a website. Also, this research informs the Functional Requirements Document to a certain extent.
Commented Sep 7, 2012 at 13:58Terms like "Functional Requirements document" are notoriously ambiguous and often misunderstood, especially when documents are being passed between design and development teams, so it's often best to define the purpose and scope of the document you are producing
Who is it for? What is being documented?
The ambiguity comes from the term "requirements" - basically, whether the requirements being documented are
In the first case, the requirements need to be documented before any design solution is attempted, and so must be finalised before the completion of wireframes.
In the second, the FRD cannot be started until there is a design solution to document, so it can't be started until the interface design is stable, i.e. late in the wireframing process.
The first kind of document constrains the design.
The second kind of document constrains the implementation of the design as code.
Content Management Requirements
This is another ambiguity that you need to watch out for.
For many web developers, a functional requirements document should contain all and any business rules that need to be implemented as part of the application. This can include e.g. content management processes and governance, which most UXers don't normally think of as something they need to specify as part of their wireframes.
Shared Understanding
If you keep these ambiguities in mind, and work with your stakeholders and developers to agree on a common understanding of what documentation is required, you'll put yourself in a good position to avoid doing a lot of unnecessary and unhelpful (and mind-numbing) documentation.
answered Sep 6, 2012 at 3:37 765 6 6 silver badges 16 16 bronze badgesGreat response! I had all these thoughts in mind but you hit the nail on the head. I agree, a term like FRD can definitely be ambiguous and answering the questions like you mention above helps a great deal in hashing out the scope and purpose of the document at the very beginning of a project. In our web dev process, the definition of an FRD is 2. constraints on the implementation of a particular design solution and it makes best sense for us to have the wireframes add additional detail to the FRD. Thanks!
Commented Sep 7, 2012 at 14:39Wouldn't these "business constraints" be referred as Business Requirements? IMHO, a Business requirement (BRD) defines a constraint, but does not "specify" the implementation of a particular design. Reversely, I view functional specification (FSD) as, as you say, "constraints on the implementation of a particular design solution". A "requirement" tells an objective to achieve, a "specification" tells how this will be achieved. This is why i think the logical order would be 1) BRD (business requirement document) -> 2) Wire-frames -> 3) FRD.
Commented Feb 12, 2016 at 0:52My favourite illustration about design processes is the following:
Don't even care about where does it come from, it's the long-forgotten old-style software design (when there wasn't separate UX and technical design, there was software engineering, and engineering processes), but it still holds the key.
As you see, all start roughly at the beginning, but their intensity is changing. These are about 2-4 week iterations.
There's no first or last: we could say: started first, or finished first.
Personally, I'd feel, that you should start with functionality, as it defines what the system is used for.
But on the other hand, users speak user language, that is, user interface. They can only explain it within a familiar environment, and that's usually GUI. In the terms of change requests, it always comes either as UI changes, or based on a strange mental-implementation model, the users' model of the system's perceived implementation.
In any way, the point is to stick to needs, not to buttons: your users don't need another button (even if they say that), they have a new problem which they want to solve with the button. Make sure you record that information, as early as possible.
Because buttons come and go, problems remain the same. Applications are about problems. They are about how to solve non-computer related needs how to reach non-computer related goals.
Your specification should be a clear systematic record of the system of these needs, just how Linné tried to describe the system of living things: your world to describe is a world full of needs and drives.
An elegant solution is the one which matches its counterpart, the problem effectively, the most simple yet most ingenious way. Elegance is minimalism in beauty.
Designers should strive for elegance, especially when it comes to applications, which are to solve user needs. Everything which doesn't deal with the problem just adds to the problem.
The UI is the system for your users. It's the metaphor of the system.
How could you expect to design an elegant solution system to the problem, if you don't have a clear description of the problem first?
Do whatever you need to understand the problem (if you need UI mockups to help users communicate about those needs, use them, if it's better with diagrams, or text, use them), and do whatever you need to have a solution to that problem, which doesn't want to solve anything else.
For that, I think a key artifact is a requirements document which doesn't detail the solution, on which the actual design of the solution system (which is usually specified in UI terms) is relying. If you design full wireframes first, they hang in the air.
But of course, this is a chicken-or-egg problem. Make sure you have both in your yard at the same time.
answered Sep 6, 2012 at 2:14 7,449 2 2 gold badges 25 25 silver badges 35 35 bronze badgesThank you for the response Aadaam. I agree, there is no first or last. In our approach to web design, the FRD typically "starts" way before we are in the wireframing phase. New information is constantly added throughout the user research phase as we glean more information about the target audiences and their needs. I was curious how others typically approach this chicken and egg problem. Do you finish your FRD, get a signoff from the client and then proceed to the wireframing phase? or do you create wireframes, get a signoff on them and then finish up the FRD?
Commented Sep 7, 2012 at 13:57@Aadaam, that's the Rational Unified Process (RUP) diagram. As originally intended, RUP was supposed to be a model for iterative development; as actually practiced in most places, its just an excuse to do "Waterfall" development where Design happens first, then Construction, then Testing. It's built on old-school engineering principles but those brick-and-mortar correlates don't really apply as much to software. I run screaming from RUP just because of what most customers and managers try to make it mean.
Commented Sep 10, 2012 at 17:56@JayStevens: I guess I'm perfectly aware of RUP. I was tqught of it and I practiced it. When I was working for a finnish company where Agile is the norm (it's that finnish company) I was running around screaming, demanding to introduce the sanity of RUP at least to some of the parts, eg. correct meeting notes, or certain kinds of documentation. They're doing Agile "right", they spend billions of euros on Agile, but Agile just shouldn't be used in a company of 100000+ people. I still demand not to start code a module until at least you have a vague idea what to code.
Commented Sep 10, 2012 at 20:19(And I'm perfectly aware of people trying to do Waterfall out of it. But as you see, RUP has 2 iterations of analysis-before-code for a whole project. I usually say, 10 percent design is the right amount as a rule-of-thumb: first two weeks of a half-year project just understanding what customers want, first day of every two week sprint, and half an hour every afternoon (or one every 2 days) just to talk about high level concepts - that's what Agile calls BDUF, while I call it engineering.)
Commented Sep 10, 2012 at 20:26When you wireframe first, you are defining a solution before you know what you are trying to resolve. You have to define the problem before you know how to design the solution. Hence, requirements state what a product needs, not the solution.
Also are your wireframes literally ideation pieces for discussion, or are you striving towards fully functional specs?
I'm a UX person, but more a hybrid between ux and Business analysis and it does my head in when wireframes are done first. I do believe that ux people should know how things appear on the site, so how it's content managed etc.
Everytime I am on design led projects we hit massive problems. And this is mostly due to not having requirements. Designers often think that wireframes are always the start of a project. They have often stated that requirements destroy creativity. I feel this is so wrong, and leads to total hell across the team at later stages of the project.
Firstly every single project needs to be approached differently. No two projects are the same, so should be approached accordingly. I always state that before wireframes are even mentioned we need to firstly understand and then balance out the following:
Requirements are divided into functional and non functional. Listing out the functional requirements early on is critical. The way they are written should be easy for all technical and non technical people.
These requirements are derived from a combination of sources:
Welcome to the site, @AKF! +1 for emphasizing the paramount importance of having good requirements before starting the first wireframes. It's worth noting that after wireframes reify the initial requirements, those requirements may change (based on new questions the wireframes raise), so that the requirements are created both before and after wireframes.
Commented Dec 3, 2014 at 0:43The team I work with has one person handling both the business analysis and design (who just happens to be me). I vary between starting with requirements and starting with rough mockups/wireframes, mostly depending on a couple of factors:
The nice thing about the written requirements is that they can be used to prevent the ambiguity that is inherent in a mockup; that said, when users see what their request will actually look like, they often come up with more requirements.
And, sometimes, I just start with a mockup because I'm a visual guy, and it helps me to figure out exactly how the requirements should be written/communicated. My super-rough Balsamiq mockups often help to inform the requirements. With this approach, I am definitely willing to toss my designs and start over once the requirements have been finalized/more finalized.
answered Sep 6, 2012 at 21:53 121 3 3 bronze badgesYou make a great point, "The nice thing about the written requirements is that they can be used to prevent the ambiguity that is inherent in a mockup". That is one of the many uses of the FRD at my agency. We use it to get a signoff on all the features, functions and details of the website from the client. Sometimes the clients do ask additional questions that they have not thought of before and it helps all of us decide what is in scope and what is not. Having this signoff before jumping into development saves everybody time, effort, confusion and more importantly. $'s!
Commented Sep 7, 2012 at 14:54I work at a consulting company, and our clients range from super tech savy and understand design and can talk server configurations to not understanding one thing about technology or design. I've kind of switched up the process at my current employer.
I've found that having a few meetings to elicit design/functional requirements is a great way to help nail down elements and functionality that the client absolutely needs to be on a page. However, I don't let these meetings stop me from just showing the client some quick and dirty sketches/prototypes to start understanding flows and interactions. With these design requirement meetings, I create a UX/Design Requirements document. It's a table in our Wiki that lists the section/content type and all the elements that are required on that page, along with very general notes about that requirement. Once that is approved, I move on to wireframing or prototyping. As I prototype or wireframe, functional documentation is being worked on for the developers.
I think having functional documentation drive design decisions before even seeing how that interaction works and feels is really a disaster waiting to happen and will only result in many more iterations than normal.
answered Sep 6, 2012 at 0:22 271 2 2 silver badges 4 4 bronze badges"I think having functional documentation drive design decisions before even seeing how that interaction works and feels is really a disaster waiting to happen and will only result in many more iterations than normal." - Exactly! It's hard for most clients to visualize a 100-page functional requirements document without actually seeing it in action! It helps them a great deal to actually see the wireframes and other interactions. At my agency, we have our clients review and leave detailed comments on the wireframes. Once everything is hashed out, we update the FRD and get a signoff.
Commented Sep 7, 2012 at 14:59I believe the requirements should be written before the wireframes and that is how I have seen mostly throughout my career. The requirements come from the client or product manager, and it is up to the UX team to translate those requirements into wireframes that will deliver the whole experience, and guide UI, developers, etc.
answered Sep 5, 2012 at 23:35 user17508 user17508I agree with you and we do that in our web dev process as well, our requirements definitely come before the wireframes. The functional requirements document I was talking about specifically details how design features are implemented via code and so it makes sense that our wireframes inform or add more detail to our functional requirements document.
Commented Sep 7, 2012 at 14:47Functional requirements come before wireframes.
Before FRs there are business requirements, which start the chain of events.
Business reqs communicate a need, something a stakeholder would like to happen.
Functional requirements communicate how things should function after the new functionality is implemented.
A business requirement could be like Allow users to login with their identities in other sites like Google, FB or Twitter. This can stem from a competitive comparison.
The wireframes for implementing such functionality could be quite obvious, copied from some other site implementing OAuth. But the functionality is not that obvious.
So it's possible to show screenshots to the stakeholders after doing a little cut&paste, and get a signoff.
But the reality of the impact of such implementation in this particular site is not known until after somebody acting as a functional analyst has understood it. Like for example it might happen a deep impact in all the back office interactions and the users database structure, requiring extensive changes everywhere and a migration plan.
This technical complexity reflects in higher development expenses.
So, after we have shown the manager a simplistic OAuth login wireframe, how can we address her a few days later asking for a humongous budget? After she showed the screens to her mean VP?
That's why functional reqs come first.
Of course, you can show her the mongrel screenshots and tell her to hold her breath while the homework is been done, but this depends on the formality level. If it's a 12-people company things are different than in a Fortune-500 one.
That said, the art of doing functional reqs involves a lot of avoiding to mention the UI. It is bad to write "set a button for the user to choose ", the FR should only state that the user has to be allowed to choose .
The great advantages of keeping the UI out of the FRs is known since many years ago (may be the seventies, I think), and is expressed in Larry Constantine findings.
A key finding of them (Larry & Lucy) was that the sooner one started drawing boxes in a programming IDE, the more time that application would take to reach an acceptable usability level.
Functional reqs frequently look like long lists with short sentences all starting with The system shall . . These are not FRs, with some luck they can be regarded as business reqs (what to do, not how to do it).
The best way to express functional requirements are through Use Cases.
But don't frown that fast. These are not your father's UCs, and definitively not RUP's UCs.
I'm reaching exceeding the lengh of a reasonable answer, so to wrapup, ideal is to write informal, lightweight UCs, to capture functional requirements.
Two main reasons:
