By Joey Lee
In this point I present a “tapas” of methods to develop requirements centered around your audience. Read more about what requirements are and why you might want them here.
👉 Step 1: Gathering and communicating your concept to others
You’re a smart, motivated, and hardworking person. You’re making a project to make the world a better place or to discover new things. However, no one was gifted with the ability to read your mind and/or search through the database of your memories of how you landed on your project idea. Therefore you must try to help others know your thinking to get them on the same page regarding why your requirements make sense.
Things you can try
I personally do all of these things when making new projects and defining project requirements, but you may find some exercises resonate more than others.
Moodboards
A Moodboard is a collection of images and references that evoke your vision of the look and feel of your project. These are images, videos, books, or anything else that speaks to the way you want your project to be received, interacted with. These things can reflect how the project creates impact, what fonts you think fit the personality of the project, what colors you think speak to the vibe you want to create, or where you want your project to live (e.g., internet, journal article, etc.). Regardless of what you include, it must be visual and ideally shareable. People should be able to make comments on it.
You can use various services like Pinterest or Dribbble to collect these references or you can just use a slide deck to post images, quotes, and other things. You can find software for moodboarding via Shopify and some tips via Canva.
Sketching and illustrations
After you've laid out which things inspire you, work to refine a better picture of your vision. Sketching can be a great way to do this. Don’t worry, no one is expecting your stroke of genius to be displayed on a napkin. What you want to convey is that you’re starting to think about the various forms that your project will take. If it is software, sketches of how you see your software helping people can be cool. If your project is community organization, you might also sketch how it might affect your intended audience. See the work of Simply Secure, star people, and box people.
User personas
Personas are a set of profiles that are meant to capture the essence of those for whom you’re designing and building. Sometimes defining personas can feel hokey and reductive, but the point is to think carefully about who might make up your audience. If you’re taking part in a user-centered design process, then you are principally designing for these people. This is a moment in which you can think about who is included and who might be excluded based on your design decisions and intended project goals. Capturing a diverse range of intended users will quickly show you where gaps exist.
Where do these personas come from? They can come from your imagination or be references to people you know. Ideally you will go out and interview people whom you think your project will serve. Get their thoughts and feelings from a series of structured interviews and unstructured conversations. After you've synthesize what they've told you into some takeaways, go back to those people and see if your synthesis aligns with their perspectives. You can define and refine your requirements based on these enlightening new pieces of information.
Check out Mozilla Open Leadership's Personas and Pathways exercise and OpenCon's Design Thinking Guide (section 3) for more on developing and using user personas.
User journey
After you’ve defined who your audience is and specific people that represent that group, you might consider to draw out what is called a User Journey. It’s one thing to see who might be interacting with your project, but it is another to see the difference between the way people are experience the world now and how they might experience the world with your project out in the world.
A user journey is very visual, often taking the form of sketches and images (think like a comic book) where you track a person through a series of interactions and touchpoints which captures their feelings and thoughts. Do this for your different users to show what life looks like before your project and after.
Stakeholder maps
In an ideal world, we wouldn’t have to worry about things like money or politics, but alas, here we are. Your project will likely have additional stakeholders outside of your intended audience. This might include funders, your university, or other communities within your domain. Mapping them out and drawing connections between then can be helpful to understand where your priorities may be aligned or in conflict with theirs. Such a map is also helpful for others to understand what kinds of “sandbox” you’re playing in so that they can be sensitive to your context.
A stakeholder map can also keep you compliant in the case that various stakeholders require different things from you to keep the 💸 rolling in.
Additional resources to help you design for your audience:
- Design Thinking Toolkit from the Amsterdam Media Lab. This toolkit includes exercises relevant to varying levels of your project’s process. You can mix and match these with the ones we've suggested, as well as come up with a process of your own. If it sticks, please share it with us! NOTE: When doing these exercises, it helps to do them with others, facilitated by a facilitator, and time-limited so things don’t bubble out of control.
- Produce Requirements Documents, Downsized, from Atlassian. This blog post outlines how to make a requirements document in a way that is not bloated and will not bog you down.
👉 Step 2: Getting closer to a list
What makes a good requirements list? How do you maintain a requirements list? What does a good requirement list look like? How do you get to your requirements list in the first place? Below are some methods that will help you define and refine a list, and then put it into a form that you, your team, and contributors can use.
Things you can try
Service blueprinting
There are heaps of ways to identify the needs and wants your project might satisfy and to define the features needed to satisfy them. One tool that is often used in product design and development is a service blueprint.
As defined in the Learning Space Toolkit,
A service blueprint is an operational planning tool that provides guidance on how a service will be provided, specifying the physical evidence, staff actions, and support systems/infrastructure needed to deliver the service across its different channels. For example, to plan how you will loan devices to users, a service blueprint would help determine how this would happen at a service desk, what kinds of maintenance and support activities were needed behind the scenes, how users would learn about what’s available, how it would be checked in and out, and by what means users would be trained on how to use the device.
By thinking through the features of your project in the context of the people you’re designing for, you might find unexpected, surprising, and even delightful ways to enhance your project. You might also find places where complexity needs to be simplified or where outside expertise might be needed. Read more on service blueprints from Nielsen Normal Group and Service Design Tools.
Deconstruction of a similar project ⇒ deconstruct another service
Articulating what kinds of specific features you want to build for your project can be overwhelming. Just breath, look around, have an ice cream. Then find a project (maybe from your moodboard 😉) and try deconstructing the features that are part of that project. You can be as specific or high level as you’d like, but the goal is to examine the key moments or touchpoints for those using your project, and the social or infrastructural resources that make those moments/touchpoints possible.
By deconstructing another project into a service blueprint, you can identify patterns and resources that you may want or need to build into your own project. This may also give you an opportunity to determine which features of similar products are not helpful or don't further your vision for your own project.
Wireframing
When you’ve got a fairly refined idea about the direction of your project, you might consider making a wireframe. A wireframe is a sketch of the visual interfaces that outline a tangible structure of the thing you want to make. In the case of a webpage, you might sketch out the placement of elements like the navigation bar, text, and buttons. In the case of an event, you might sketch the locations for tables and chairs, which direction they'll be facing, and how people will be able to navigate the space.
Wireframes can help you visually start expressing what requirements you’ve outlined and allow you to visually identify what things you might have missed.
👉 Step 3: Synthesizing features/requirements into a list
By now you’re probably thinking, "Are we ever going to make a list of requirements?" The answer is, "yes!" More accurately, you will be making and refining your requirements list over and over again. We hope you like lists! Below are some methods and tools that might be useful for building out your requirements list in a way that is accessible and easy to update.
Things you can try
Saturate and group
You’ve probably got a largely unstructured set of insights you’ve now drawn up from all of the above exercises. All of that stuff is likely jumbled in your brain, unorganized and largely overwhelming. This is where the "saturate and group" exercise might be of use.
Saturate: Print out all of the material you’ve gathered – all the ideas, insights, and things you need to make your project happen. Spread them out and write each one down on a sticky note.
Group: Now, make a first pass and start clustering your requirements into related areas. Think of a clustering that makes sense for your context. For example, in the case of a web app, cluster by front-end, back-end, databases, etc. Or in the case of event organization, cluster by before, during, and after the event.
Project Management Software
It’s project management software time!
At last we’ve got grouped sets of requirements. They are probably a mix of higher-level needs and super-functional components. For tips on how to differentiate between higher-level requirements and low-level implementation specific details, please see: <INSERT LINK HERE>. It is probably a good time to get those things into a workable, usable list that will guide your project development.
There are a zillion project management software options to choose from. Of the zillions, I tend to use:
- Github Issues ⇒ Github Projects Management ⇒ Milestones
- Trello
- Asana
👉 Step 4: Do it all again
You’ve just created your requirements list and you’re making progress. It is important to reflect and evaluate that progress. Are you meeting your goals? How have your goals changed over time? How have your users changed over time? In what ways have your priorities shifted? Why? All of these things are going to change what features are hoisted up or pushed down your list of priorities for making your project happen.
Put a reminder in your calendar to spend an hour or two doing some project housekeeping. Go over your requirements list in 3 weeks, 6 week, 12 weeks, a year, etc. This simple intervention might save you a lot of time down the line. Clean up your requirements and make sure they reflect the current status of the project.
KEEP COPIES. If you’re not using version control, it might be good to see how your requirements have changed over time. This is also a good practice for making sure that stakeholder expectations have been met or at least that you’ve communicated how the project has changed over time and your project ecosystem is operating with a common understanding.
Contribute your requirements method!
Want to contribute how you produce requirements? Please do! We’d love to hear your methods. If you have a personal story you’d like to share, email us at [email protected].
A note from the author:
After reading this section, you might be thinking, "Hey, all of these methods are design methodologies for brainstorming and concept development." And you’re absolutely right. You are designing a project, an environment, an event, or a community, and it is therefore fitting that you use tools that can help facilitate that work. The requirements to make your project happen are closely coupled with the concept, the interactions, and the end outcome of your vision. You can apply these methodologies to broadly to approach any project or question you might have.
There is also loads of room for improvement here, and you might have your opinions on useful exercises and ways to define project requirements. We’d love to hear if these methods are useful!
A note on facilitators: Many of these exercises benefit from having a facilitator who is practiced in these methods and can keep you on track. It helps to work with and around others, being cognizant of time and ensuring you synthesize the output of each exercise in a way that can help you lead to your next decision. Hiring a facilitator can be really helpful. Or you can ask a favor of your favorite User Experience or Service Designer friend to help keep the flow.