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