{"id":374,"date":"2024-12-24T16:12:42","date_gmt":"2024-12-24T16:12:42","guid":{"rendered":"https:\/\/bendauphinee.com\/writing\/?p=374"},"modified":"2025-01-07T17:30:09","modified_gmt":"2025-01-07T17:30:09","slug":"designing-an-app-from-scratch-part-2-wireframing-requirements","status":"publish","type":"post","link":"https:\/\/bendauphinee.com\/writing\/2024\/12\/24\/designing-an-app-from-scratch-part-2-wireframing-requirements\/","title":{"rendered":"An App From Scratch: Part 2 – Wireframing Requirements"},"content":{"rendered":"\n

7 minute reading time; ~1325 words<\/p>\n\n\n\n

\n\n\n\n

Welcome back!<\/p>\n\n\n\n

Today, we’re going to talk about wireframing from our requirements and stories, and exploring how talking through a wireframe helps us refine our specifications. <\/p>\n\n\n\n

Between the last post and this one, I’ve taken the requirements and user stories that we wrote about, and cleaned them up into a project plan<\/a>. The documentation is still light, and that’s intentional, as we’re focusing on a very narrow scope of work; we want to get the basic template management and editing up and running first.<\/p>\n\n\n\n

By the end of this post, we will have some refined wireframes and requirements, and a firm foundation for working on workflows and technical requirements!<\/p>\n\n\n\n

If you haven’t read it already, I’d suggest you start at An App From Scratch: Part 1 \u2013 What To Build<\/a>. You can also find all the related documents and code here: Building Tailgunner<\/a>.<\/p>\n\n\n\n

Wireframes<\/h2>\n\n\n\n

From our initial project plan, I created wireframes based on two user stories (US1<\/a>, US2<\/a>) to illustrate the requirements. These wireframes are intentionally not high-fidelity, focusing on interaction points rather than exact design details.<\/p>\n\n\n\n

Initial Designs<\/h3>\n\n\n\n

After carefully reading both user stories, and the requirements in them, I’ve made a wireframe of both pages that cover what is needed from the requirements. Below, you can see the template list page, showing some mock information, and covering the details from our second user story.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

You can see how the requirements translate into an actual interface, and how many unspoken requirements or ideas are included in the mockup that aren’t in the documentation itself. For example, you can see the dates aren’t absolute dates, but rather relative dates, making them easier to read and work with.<\/p>\n\n\n\n

This is a medium-fidelity wireframe<\/strong> (low-fidelity<\/strong> is usually sketches on paper). This level of design is detailed enough to have a conversation about the stories and how they translate, but not so detailed that you’re locked into specific design choices. Later, once we have a solid agreement, and are working toward final technical requirements, the design team (or I \ud83d\ude06) will generate high-fidelity wireframes<\/strong>, which usually have specific color and layout choices, and are much closer to the finished product.<\/p>\n\n\n\n

Note: the icons only have color because the design set I used had them. Overall it’s recommended to minimize color usage in a mockup like this. The idea is to figure out if we have the right elements to cover the requirements and make the tool usable, not to convey the exact design.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Breaking Down The Elements<\/h3>\n\n\n\n

Here you can see how each story is broken down and applied to the wireframes we’ve put together. In yellow notes, you’ll see each requirement, and the wireframe elements that it matches, and in pink, you can see assumptions or mistakes we made in the designs.<\/p>\n\n\n\n

As part of the review and discussion around the initial wireframes, these assumptions and mistakes should be addressed, and either added to the requirements, or removed from the wireframe and noted as out of scope (this way we have a record of what we have explicitly considered and chosen to exclude).<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

Revised Requirements<\/h3>\n\n\n\n

Now that we’ve reviewed our requirements in context of an actual wireframe, and highlighted the talking points, it’s time to revise our requirements to better align with stakeholder expectations.<\/p>\n\n\n\n

\n

US1 – User Story<\/strong><\/p>\n\n\n\n

As a business owner, I want to create a custom form template based on my needs so that I can capture specific data unique to my workflow.<\/p>\n\n\n\n

Acceptance Criteria<\/strong><\/p>\n\n\n\n