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?
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
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.
My 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.
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:
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:
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:
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.
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 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.
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:
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:
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.
