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?

  • 1
    I 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
  • 4
    How would you know what to put in the wire frames without knowing what functions are required? Commented Sep 6, 2012 at 5:57
  • Marjan - 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:58

12 Answers 12


Terms 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

  • Before you begin, to get agreement on the content and format
  • In the document itself, to avoid misinterpretations and tangential feedback

Who is it for? What is being documented?

The ambiguity comes from the term "requirements" - basically, whether the requirements being documented are

  1. business constraints on the behaviour of any valid solution to the design problem
  2. constraints on the implementation of a particular design solution

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.

  • 1
    Great 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:39
  • Wouldn'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.
    – Yann
    Commented Feb 12, 2016 at 0:52

My favourite illustration about design processes is the following:

A well-known illustration of the RUP process

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.

  • Thank 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
  • 1
    @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.
    – Aadaam
    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.)
    – Aadaam
    Commented Sep 10, 2012 at 20:26

When 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:

  • know your users ( user research )
  • know your content ( audits & modelling, subject matter expert interviews )
  • know your editorial process ( workflows & governance )
  • know your business ( business model )
  • know your systems ( CMS & controlled vocabulary management & governance )

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:

  • business needs and wants
  • user needs and wants, which can come from different user research methods
  • editorial needs (if it's a full end to end project)
  • 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:43

The 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:

  • Complexity of the task: if its something simple, I'll probably just jump to a wireframe
  • In-person or distance review: if I'm going to be distributing to people geographically separate, I'll start with written requirements and then transition over to a wireframe
  • Technical v. non-technical: If the request is for something technical/complex, I'll start with written requirements

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.

  • You 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:54

I 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.

  • "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:59

I 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.

  • I 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:47

Functional 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:

  1. They are the hinge between the users and the IT people worlds, and
  2. If well written the UCs make coding faster and safer, and thus much less expensive.

It all depends on the project. Whomever is working on gathering business requirements and doing user and competitive research will need a certain level of understanding before a vision appears and the magic starts happening.

I'll offer another approach, which I don't particularly prefer, but don't mind at the moment. I'm working with a colleague on a project where the client insists on a combination of annotated wireframes and interactive prototypes without knowing the requirements. They use the wireframes for quick internal review and the prototypes for even quicker testing then use the data to build on previous work. This process isn't driven by user needs and business requirements because those are both generated as we progress.

In this project, the FRD is written at the last possible moment for the developers only with all the additional wireframes and interactive prototypes available as references. I wouldn't recommend this method, but the client likes to work this way for certain aspects of their business and it seems to work for them. You could say they like to think outside the box.


Lots of great thoughts here on a subject that I'm clarifying with a client at the moment.

How I see it is that the two (wireframes/prototypes and FRD) are so closely intertwined it does not matter "There's no first of last" what is more important is neither is completed (signed off) until the other is in a comparable agreed state.

If a FRD is to detail the business rules, data requirements (sources) and functions the business is wishing to expose to the user, the business needs to commit to or confirm that this data will be available when it comes to designing the interface and IA this data/functionality is to be delivered through. Without this confirmation the datas existence is in my experience sometimes questionable as the foundations being relied upon aren't always as sound as hoped.

The business rules, data requirements and functions are all design challenges at this point, almost no one who represents the business will fully appreciate the detail or lack of included in a FRD.

As designers our role is to interoperate the FRD (a design brief if you like) into something meaningful - meaning presentable and understandable - that answers and importantly challenges the concepts and requirements within the document. At this point we have stuck to "needs not buttons", familiar methods of navigating common information are applied together with enough detail to ensure the complexities or this particular business are made available in comprehendible ways that are built upon sound foundations.

Without these sound foundations much of the understanding gained through research, design and prototyping can be made invalid in an instant. Rarely can this be rectified with the addition or removal of buttons or functionality as each element often relies upon others being present for the context that informs and confirms a users metal model of what they are navigating or gaining access to.

Again as Aadaam notes "There's no first or last", they are one in the same thing.


You could to some extent.

But you'll find yourself working on top of what was previously thought. And that may lead to unsupported functionality over a deficient site structure and layout that will not cope with surging ideas.

Better create a functional spec that will not go beyond key interactions, sitemap, and navigation.. And then.. well you will have to redo and update.


Waterfall = requirements come first. Agile = they are developed in parallel.


For web app development, I suggest to create several documents that you update/maintain parallel as you grow:

  1. 1-5 page summary about the app, what's the story line
  2. define all possible user roles - and stop referring to user after that. It's registered, pro user, admin user, owner, viewer, etc.
  3. define all possible pageviews you can think of. Login, home, notification settings - without setting up any hierarchy
  4. list all possible actions each role can do, regardless on which page. Login, like, comment, delete own comment, etc.
  5. each app will have something unique, e.g. auction, voting, ordering process, etc. For those cases draw a flowchart to cover all possible outcomes - for more advanced users try swimlane flowchart, very helpful.

As you go through each step above you will discover a new element, keep improving your story line and steps 1-5 until you feel ready to start wireframing. Technical requirement can be inserted as notes directly in wireframes.

Another boring document I suggest to maintain is the list of variables for each page. Field name, type, drop down options, required field, validation, default value etc - for advanced users, use database diagram.

Using this method you can create wireframes in no time without constant block.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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