Functional Specs 101

I am taking a course on production pipelines and project management. Knowledge of project management is a great extra to add to skill sets of UX researchers/designers, who are going to serve in a product team and work closely with other functions such as UI designers and developers.

As the UX lead in the course project, I learned quite a lot about the streamlined product development cycle. We as a whole team went through the confusions on procedures of creating Functional Specs, and how to integrate other UX research steps such as user research and wireframes into the writing of Functional Specs.

Here, I am going to share my understandings and learning notes based on several readings and class practices on Functional Specifications (Functional Specs) basics and its role in project executions. I am trying to achieve this goal by asking the following 3 questions:

What are Functional Specs?

In a nutshell, Functional Specs are documents that specify the “what” and “how” of a product – What is the product set out to do? How does the product look like? How do users interact with the product? What are the technologies to achieve the functions? It should include the purpose, look, and behaviors of the application.

Why we need Functional Specs?

  • Function Specs serve as roadmaps for product development. By nature, it provides both the landscape and all the necessary details of a product, which meet the requirements of stakeholders, to the developers. Thus, I view Function Specs as the bridge between frontline-clients/users and backstage developers, groups that are vital in product design but might not have a chance to direct communicate with each other.

Function Specs as a Bridge

  • Function Specs help to streamline the product development process. Through writing Function Specs, the product team can gradually move from chaotic information-gathering stage (with ambiguous and different understandings/inputs)  to reach an agreed vision of the product.

However, this happy ending needs to be built upon quality procedures to create the Functional Specs.

How to write Functional Specs?

  • Do the research to define the product.

This stage is what most UX researchers are familiar with. At the early stage of product development, researches are needed to generate a clearer definition of the product. I view this early-stage research system as a bi-directional system: top-down research approach and bottom-up research approach.

By top-down approach, I mean conducting comprehensive analysis on precedent similar products to (1) avoid reinventing the wheel; (2) get a quick understanding of the product through a short cut.

Bottom-up approach, on the other hand, requires more time and efforts to learn the target users as well as communicating with clients to define the product. User-centered design methods such as ethnographic study, contextual inquiry, interview & focus groups, and task analysis can be used to this end.

  • Create the designer model / represented model.

After gathering and analyzing all the data, models can be used to represent research findings. As pointed out by Allan Cooper in About Face 3 (a must-read for UX designer/researcher), there will be 3 models in a product: users’ mental model, represented model (or designer model), and implemented model (or programmer model).

Users’ metal model represents what users see and understand in front of a product – a perceived product.  This can be studied and represented as persona and persona-based scenarios.

Implemented model or programmer model is the actual mechanism that runs the product, mostly only understood by programmers.

The huge gap between users’ mental model and implemented model is bridged by represented model (designer model). It is through this represented/designer model that users interact with the product. Thus, Cooper pointed out that a good design is having a represented model as close to users’ mental model as possible.

Mental Model, Represented Model, and Implemented Model by Allan Cooper

Mental Model, Represented Model, and Implemented Model by Allan Cooper

Since the represented model is the exact layer we are designing, it becomes the focus of the Function Specs writing. Meanwhile, its bridging nature also means that whatever we are designing on this layer, we should always keep users’ mental model and technical limitations in mind and open the communication channel to stakeholders and programmers.

  • Design the information architecture.

So, when we focus on the represented model, what exactly we should consider? The first and foremost step, as what we learned in sketches, is the architecture of the application. Try to think about these questions: What are the key pages users need to visit? What is the function of each page? What elements and contents should go to each page? After answering these questions, we will be able to establish the structure and flow of the information.

At this stage, flowcharts, interactive prototypes, and wireframes can be very helpful to organize thoughts, represent results, and provoke discussions. Wireframes are extremely helpful to gather stakeholders’ feedbacks on functionality and architecture of the product because it strips out distractive design elements entirely. The core objective at this stage is to get the represented model onto paper, in the form of flow of key pages and navigation design.

  • Design documents

Design documents can be viewed as pre-Functional Specs documents. We can put all we have together and document all the feedbacks. Based on this, more detailed Functional Specs can be built. A lot of iterations will happen at this stage, including redesign of information architecture, visual appearance, and detailed interactions. Through several iterations, the team might be able to get to a clearer view of the product and reach final consensus.

  • Functional Specs

Here comes the final step. To this end, we need to write up the Functional Specs to put everything we’ve been discussing and improving on the paper. This again, makes sure that our clients are aware of and agreed on what we are going to built and the programmers have the “Bible” that they can refer to. More technical requirements (say, which development technologies to use) might need to be discussed with programmer representatives.

So, in the end, what makes good Functional Specs? Check if the Functional Specs have following characteristics:

  • Blueprint. The Functional Specs should give an overview of what this product is about and who are the target users. This helps to build the consensus among the whole team. However, don’t include unnecessary research data (especially those “raw data”) to confuse and overwhelm programmers. A clear table of content is also very important to facilitate a holistic understanding towards the scope of the product.
  • Exhaustive details. Try to include all the teeny-tiny interactions going to happen in the app. Company the explanation with corresponding screen shots. This could be harder than we thought – there might be a lot more “what-if” situation that we didn’t fully consider, which could cause a lot of confusions and communication cost once deployed to programmers. Practice and a good eye is needed.
  • Consistent and concise writing. Use the same design language throughout the document. Don’t use two terms to refer to the same elements. For example, do not randomly use “drop-down list” and “drop-down menu” interchangeably in the same document.

This learning notes are based on class materials, and some more readings, especially the following two. They provide clear and in-depth explanation on Funcional Specs, with great examples.

Functional Specs Tutorial by Allen Smith

Painless Functional Specs Tutorial by Joel Spolsky

Next time, I will briefly review the Agile development model and discuss how we adopt it in our projects.


7 thoughts on “Functional Specs 101

  1. billzhangpitt

    That’s very informative notes. Thanks for sharing! I took Information System Analysis (i.e. requirement management) class in grad and learned similar topics, though from a software engineering point of view. I think the functional specs here resembles requirements documents, which by definition is an agreement between all stakeholders about what a system should do and how to do them.

    However, I have questions in your categorization of “top-down” and “bottom-up” approach. In my experience, a complete product research should contain both activities as imperative parts. Only doing “top-down” (or I would call “horizontal”) research could result in lack of innovation, while only doing “bottom-up” (or “vertical”) research could lead losing in competition.

    Anyway, great article! Can’t wait to see your thoughts in design and agile process (there has been quite some struggling there).


    1. Emma (Zhihua) Post author

      Hi Shaopeng,

      Great to meet you here! Thanks for your thoughtful comments.

      Sorry I didn’t make it clear. I also believe we should do research from both directions, and thanks for offering the reason behind it. Horizontal and vertical are probably a better metaphor than “top-down” and “bottom-up”.


  2. ariadnacaixach

    Wow! Very instructive! It was interesting to learn about it but I have to admit that sometimes I had to read some parts twice. Anyway, very well-written and exposed!

      1. ariadnacaixach

        yes, I know! But I found it and I said come on let’s read about design, research, product… that sounds interesting! 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s