February 24, 2019
Code & Design
We’ve finally arrived at the module the majority of the world is familiar with: the mockup module. While the previous modules contained deliverables that aren’t as well-known outside of design circles, the deliverables included here align with the core of everyone’s expectation. The goal this time around is quite simple: design the darn thing!
No blank-page syndrome here — through three modules we’ve armed ourselves with a total of six documents for guidelines. We know exactly what to design. Refer back to the UX Wireframes for a second, & if you haven’t already, make a quick check-list of all the views in the final version. With this checklist in hand, it’s time to move through this module’s four deliverables:
Deliverables
We’ll start by piecing together realistic mockups, however, we’ll limit the decisions made on UI & branding elements by delivering strictly black & white (greyscale) mockups. Next, we’ll compile the decisions made in the grey scale mockup — UX elements such ascards, rows, & shadows. After that, we’ll swing our focus back on the mockups, zoning in on UI & branding elements such as typography, color palettes, & iconography. With a batch of high-fidelity mockups in our possession, we’ll move on the final deliverable: a realistic, tangible prototype that’s sure to delight stakeholders, teammates & clients alike. Let’s get to it!
Greyscale mockups are exactly what they sound like — strictly white, black, & grey renderings of an entire product. It’s a natural evolution of the UX Wireframe(s). While the UX Wireframe views are represented by rough polygons & titles, this deliverable contains the first iteration of app-like UI elements.
The color palette is left in greyscale in order to constrain our focus & decision-making on color-agnostic UX elements listed below. Share these drafts as frequently as possible with anyone & everyone — then iterate, iterate, iterate. Once satisfied with a batch of iterations, it’s time to move on the next deliverable by analyzing & compiling all decisions made during this deliverable. Through the Early UI Kit, we’ll summarize foundational UI elements such as rows, cards & border-radius degrees, resulting in a first & early version of the UI Kit. The overarching goal of this deliverable is to completely finish laying out the user experience so that in the remaining deliverables we’re simply cycling through multiple visual & UI elements until we find a set of elements that match the brand we’re aiming to reflect.
The Early UI Kit is a design document that summarizes, based on the Greyscale Mockups, a set of consistent, brand-aware UI Elements. Commonly among these UI Elements are:
I’ll clarify that the example above is a finished UI Kit & not an Early UI Kit as it includes color palettes & typography. The template provided, however, serves its purpose as a starting point. Remember, this first time around we’re not completing the document; we’re only summarizing the elements listed above. If done correctly, the completion of this deliverable & the Greyscale Mockup set the stage for a series of rapid iterations with the remaining UI elements.
Let’s travel four modules back. Recall that, in the very first module, we covered the many reasons that justify implementing an entire design process. Among these, probably the single most important reason stems from the fact that every product needs to satisfy multiple parties, whether that’s additional teammates, stakeholders, or clients. It’s inevitable that disagreements will arise & it’s my experience that the largest, most vocal differences in opinions rear their heads during this deliverable. Why is this? Attribute it to a sense of familiarity & finality.
First, everyone is familiar with what a finished app looks like — therefore it’s easy to compare, anchor & put forth ones opinion, especially as a nontechnical or non-creative stakeholder. Providing feedback on colors, fonts, gradients & the like is something everybody feels comfortable discussing. The other deliverables simply aren’t as popular outside of design circles, so naturally, it’s harder to elicit feedback during those deliverables.
Second, since high-fidelity mockups signal the coming completion of a product, the urgency to get ones point across to the designer suddenly spikes. Which means that those involved in the process that remained on the sidelines with none or relatively-little feedback are now likely to overcompensate by dropping voluminous amount of feedback.
Individuals don’t build products — teams do. But receiving feedback from multiple elements of a deliverable, from multiple fastidious individuals is almost always a sure-fire way to burn a designer out. That’s why the setup for this deliverable is critically important: in order to preserve our (the designers) sanity & time, it’s absolutely crucial that we identify & communicate the exact elements that we’re open to feedback on. As briefly mentioned above, the list of elements that we iterate on in this deliverable is strictly limited to the following:
This deliverable is not for updating the UX, changing the scope, or suggesting additional features. Give all parties involved a proper heads-up by communicating the list of elements above before presenting our first iteration of high-fidelity mockups.
The overarching goal is pretty simple yet can turn quite tedious: this deliverable culminates with the first realistic representation of our final product. As outlined above, expect an unusual amount of feedback, however, don’t let that clip our momentum — hedge against it by clearly communicating the feedback constraints.
The metaphorical cherry-on-top, this final deliverable, a clickable prototype, is guaranteed to delight all parties involved. These days, plenty of tools are available that help construct an animated, “clickable” prototypes; it doesn’t matter if we pick up InVision, Sketch Protoypes, Figma, Adobe XD, etc… the principle for all of these tools is one & the same: to provide an exact replica of an engineered final product with static, high-fidelity mockups.
As a quick side-note, it’s worth mentioning that we’ve found this prototype deliverable to be a phenomenal tool for convincing stakeholders (such as investors or budget gatekeepers) to commit capital in order to continue through the engineering phase. If a picture is worth a thousand words, then a prototype demo is worth a thousand pitches & projections. Additionally, we’ve also discovered that for entrepreneurs attempting their first product play, it’s highly like that they’ll receive magnitude cheaper scopes for engineering work when they present dev shops with all the deliverables included here, up to the prototype. An unfathomable amount of client-consultant scope time is spent simply trying to communicate the client’s idea as clearly as possible; show up with these deliverables in hand, & they’ll save both themselves & the possible engineering team tens of hours of communication — which translates to serious cash savings on for our fellow entrepreneurs.
We’re now a single module away from completion! This is by far the lengthiest of the modules so a congratulations is in order — we’ve now successfully completed the bridge from idea to tangible product.
The journey, however, isn’t quite yet over: now it’s time to battlefield test our baby with possible early adopters. Remember the cohort of evangelists that we surveyed back in Module I? The entirety of the next & final module, the Validation Module, revolves around extracting & iterating on as much organic feedback as possible from that very same cohort.
sources
