Reflections on Building a Feature Brief
The Back Story
Over the last week and a half, my AC4D classmates and I learned about a communication tool called a feature brief. It is precisely what it sounds like, a living feature brief explanation of what the design is, use to share the design you put together with anyone and everyone involved in building a product. The intent of a feature brief is breadth, a high-level walkthrough of a product’s features, and why.
What is interesting is that there is an element of still storytelling and persuasion involved, to communicated the value my design could have given the insight I’ve found from user research. I found this to be the most challenging part of the assignment. However, as this is a student project, and a fast pace one at that, I did not have nor did I made the time to consider ‘what is the value of this app I am making?’, ‘why might someone find this valuable?’. So in the process of going back through I realized that the type of testing that was done in the past (user testing), was not robust enough for me to initially speak confidently about the features of this iOS Banking App I redesigned for UFCU. I found myself going back and forth through my past notes from research, past presentations on this project, and repeatedly asking myself ‘Why did I do this again?’
The effort was not fruitless, but it was something that took much combing through my documents and data to write something that I would feel confident and sincere about.
Why a Feature Brief
A product feature brief is most useful as a live document, that is curated for all partied involved in building a product, that is not familiar with the design of a particular product (i.e., legal, developers, marketing, sales, business, other design teams, etc.). I communicated what the thing is, why was it made, what it hopes to provide for the user and the progress of the project. By creating an actual document to share, you literally put into the hands of other an artifact that they can comment on, critique, provide feedback, or make design edits requests. It is a powerful tool for communications and co-creation. It also invites colleagues to become vested by contributing to the design.
Building a Feature Brief
The Slide Deck. I started with place holder slides in a presentation building tool (Keynote). It was easy enough to create the outline of a feature brief: overview, insights references for design decisions, a roadmap, features & their capabilities.
I started with the cut and dry content the roadmap and features & capabilities. The features &capabilities worked out to be the bulk of the slide deck. After all, this is a feature brief. While creating the features & capabilities slides, I would use two guiding ideas to determine how much detail to provide.
- Is this a core feature that enhances the user’s experience?
- Present a 50/50 ratio of ‘What’ the thing is, and ‘Why’ was it made for a person to use.
I completed as much as I can, and found that they ‘Why’ portion was left blank. To get to ‘why’ I designed the features as I did, I went back through 3 months worth of research, variations on builds, rewatching user interviews & testing recording, and hand-written user testing notes. Here are some of the more useful content that helped me with the Overview, and insight sections and recalling why I made the design decisions I did.
User goals found during user interview and testing.
Research Result (Key Takeaways)
Some design recommendations that contributed to design decisions.
I want to share with you a PDF of all the re-research and feature brief build out.
Personally, when it comes to making anything, I often find myself that I often need to know WHY I am doing the thing I am doing. A huge reason why I’ve quit my job and when back to school to become an interaction designer was because I need to know the reason behind my efforts. Without a concrete product in hand, and people using it and providing real-time feedback it was so easy for me to become paralyzed every time I sat down and tried to put words to these features.
1. Not having everything, is not the same as not having anything. Don’t be so quick to poorly judge the quality of all the work you have done so far when you can’t find all the answers you need immediately. I need to remember that I did have a reason in doing what I did so far, and need to go through all the foundational work I have done so far to remember the value I was trying to create for users.
2. Keep sharing reflections after every design stage. Presentations that include key takeaway, insights, and results are SUPER helpful to be able to keep track of all you did and why.
3. Adding slide numbers is the first thing you need to do when building a slide deck. After creating a clean feature brief that I was proud to share, and getting it printed, I found that forgot to add slide numbers for my audience to follow along! It was a bit painful to see considering how much attention to detail I paid to all other aspects of the brief. I’d imagine it would be what J. K. Rowling had published her first Harry Potter novel and found that they misspelled her name to be JK Rolling. All that effort and messing up on a small detail can affect the way your audience experiences what you made.
What I would do differently.
- Include in my user testing, more robust interview questions to understand what makes a user tick, what they find valuable in the interaction I am designing. I would do this without any prototypes for them to play with so that I can learn about them, without the influence.
- Maintain my research results, key takeaways after each phase of the process, user insights, and results from the process. It is a great way to track the work that has been done and why.
- Work on connecting the features more to the insights. Try adding user research results to help sell the design idea.
- Frame the brief in a way that it is easy to remember what the app does. (i.e. what is the goal? what is the problem to solve?)
- Treat the roadmap less like a plan of action, and more of a rough estimation of the order of priorities.