<aside> 👋
This, and all of the blogs, give an overview of the process and steps taken for each part. I’ve included images taken from the FigJam boards where the majority of the work lives to illustrate the process.
If you would still like to see further details on each part, please view the FigJam board in full.
It can be found at the end of this page, or on this master page.
</aside>
I want to preface this page by saying I struggle to write about wireframing. For research parts of the project, each is nice neat step with a beginning, middle, and end; and typically last a couple of days. I’ve spent over 2 weeks wireframing, an if recorded every decisions it would be horrible for me to write and worse for you to read.
I’ve instead collated some key decisions in my next blog “Design Decisions”.
This blog is more of an overview of the way I wireframe.
I don’t like grey boxes. This is something I found over placement and have continued to this day. Rather than using grey boxes and helvetica, I like using a sketchier style of wireframes, that looks intentionally un-designed. This isn’t just for my aesthetic preferences, as I find this helps me focus less of pixel perfect wireframes and getting a head of myself with styling.
Additionally, I find this style work exceptionally well for testing. I often find when you show users, and particularly clients, something using grey boxes and Helvetica, they can misinterpret somethings as part of the actual styling, and focus on those instead of the purpose of wireframes, which is to establish structure, content, and flows. This sketchier style means there’s no mistaking it for intentional styling, and puts the emphasis back on the purpose of the wireframes.
When wireframing, I like to keep as many annotations as possible. I basically turns the wireframes into user flows, and helps me weed out any dead ends or issues. I also try to record as many variations and overlays as I can, rather than just duplicating screens.
For this project, I’ve started versioning already to keep track of changes. I think this is particularly useful for this project as it will let me move onto more developed screens before fully finishing the system map. Due to time, I think it will be useful to move on to Hi-Fi before 100%-ing the system map.
Full working and documentation of wireframing can be found in this FigJam file.