Lo-Fi / Hi-Fi mocks - What's better & WHY?
Does it make sense sticking to Low-Fi (low-fidelity) mocks as opposed to the Hi-Fi option as for product teams?
Few slices from history…
SLICE-1: Problem Identification
Roll back in time to the early 2000s & the late 90s. Teams speaking highly of the phases of the SDLC (Software Development Life Cycle) over what was the waterfall model of software product development where every phase remained mutually exclusive to the other was a common sight. Also:
Design (although minimally spoken of) had to wait until all requirements were gathered, rechecked for gaps & cleared thereof
Development was largely siloed & kicked-off post design assets were checked in & handed over
Acceptance testing deemed to be the final step before project closure had a huge TAT (turnaround time) from the initiation stage
This visual isn’t alien to anyone in Tech although the actual source seems totally lost in obscurity.
Such memes (although it was not popularly referred to by that name) became pretty commonplace owing to how the consensus collected over the ratio of [software produced : software adopted] pointed to many problems across stages. That’s perhaps what prompted many to hop on the bandwagon of Agile gunning for better collaboration, only reemphasized by this visual above.
Q: But did that solve the problem entirely?
A: Perhaps NOT, as many still seemed to struggle to cope with the intricacies of the new processes…
SLICE-2: Struggles, real struggles & more struggles…
It is around this time (early 2000s) that orgs. (esp. product orgs.) began to understand the gravity of the situation leading them to believe how having a dedicated Design team in-house so as to enable the course of building products with an impeccable UX / UI was imperative.
But as it is said & also widely believed, the solution to one problem could prove to be ephemeral landing one onto another problem…
Take the Y2K bug for instance which was to do with date calculations where the system perceived the 1st day of the year 2000 (right after 31-Dec-1999) as 1st-Jan-1900 given how only the last 2 digits of the date were considered. A (no-brainer) solution to that was to “consider the whole year 4-digits” which solved the Y2K successfully. But if you observe that would continue to hold until the year 9999, which paves way for what could be termed the Y10K problem.
The problem here was Design teams being internal to an org. didn’t largely participate in discussions with the users (which although dire, does continue to exist to this date at some places). The term “triad” evolved as Agile came of age, but it wasn’t practiced worldwide which may have led to gaps over understanding the outcomes that specifically represents the user’s ask, with the project manager / business analyst in traditional IT service-based orgs. & the product owner / product manager usually taking up the job of providing clarity for design teams.
Q: Did it solve the problem?
A: Absolutely NOT, given the new process the whole workflow seemed to be in a mess & coping with it seemed to overtake the priorities of all the teams & delivery largely suffered both in quantity (cadence) & quality
SLICE-3: Problem Resolution
PMs & other middle-level managers did stand-in for the clarity required for teams to help progress towards the outcomes. They chose to do that via documents they thought was relevant. This may have led to the birth of the BRD, FRD, MRD, PRD eventually translating into highly specific docs as required by individual teams (for ex: Docs meant to provide clarity that’s oriented towards the architecture - HLD, LLD, ERD etc.).
A typical MRD / BRD ran for 25-30 pages and how it was perceived gruesome (not to mention a total bore in many cases) did eventually lead to the development what could be called the Agile-PRDs and the more common Amazon-1-pager / 6-pagers that are in use industry-wide as of today.
Q: Was the problem solved now?
A: Majorly yes, but there was always information getting lost in transit as it cascaded from top-bottom & of course there was still room for improvement in terms of the collective efficiency & productivity…
One primary causation would be how design teams sometimes are handed with fully-developed / evolved versions of the screens via a Hi-Fi Mockup and are tasked with merely converting that into a workable design asset like a collection of frames / tabs / webpages towards essentially representing the user flows using tools like Figma, Adobe XD, Sketch etc.
Q: Why is that a problem?
A: Because every designer individually / collectively as a team looks for freedom to ideate over arriving at the best possible way to help the users reach an outcome sans sweating it out, ensuring that they deliver an absolutely top-notch experience all throughout. And spoon-feeding would obviously be deemed as depriving them of creative freedom viz.:
freedom to brainstorm
freedom to ideate
freedom to collaborate
freedom to innovate
towards arriving at the best approach to the problem & the solution thereof.
Spoon-feeding ideas in the way of screens to the design teams could prove to be the bait that drags the leadership & the org. right into a puddle of dirt, a righteous old mess. And identifying whether or not one’s going to land in such a mess could be done by checking for these parameters:
design teams feeling tied down & their efforts getting fractured
designers feel like there is no room left for creativity
designers begin working in silos & don’t seem to collaborate enough
design teams’ focus is now averted entirely to rollouts & deadlines
users disconnect with the topology / flow
adoption patterns being to turn sour very quickly after release
designs totally lack stickiness
Needn’t take much to learn that one’s best bet is to gauge & identify the disconnect between design & the other teams over the first 4 points, because if one finds themselves at the latter 3 one knows the situation may have got out of hand & may be too late.
Q: So, what’s the solution here⁉️ How does one tackle this⁉️
The answer simply lies in the quality of input handed to the design teams. Keeping it basic (or I may even go as much to say - vague) advocating the use of wireframes / Low-Fi mocks which does make a lot of sense as it would then give the designers a clear starting point which describes the problem to them, leaving them all on their own to apply their thought process working towards evolving it into designs that are the skeletal basis to a winning user experience (UX).
Moreover, at a stage when the product is getting built it makes sense to keep it Low-Fi given how everything could still be very fluid, and the time one spends on it could be minimal owing to how it just ought to convey a basic idea / set an expectation which then could be easy to subject to tests facilitating changes over new iterations thereof.
So, as for the picking Low-Fi mockups as a default choice, please do remember this:
Low-Fi Mocks could prove to be advantageous owing to how they satisfy one or more of these:
Can be created easy & fast
Can be created by anyone (not necessarily a designer)
Cost-effective
Easy to change
Facilitates iterative & incremental development
Facilitates learning via the feedback loop evolving designs further
Facilitates proper step-wise methodical process (for ex: Design Thinking)
Improves probability of success manifold post-release
Ensures just the right effort is put & in the right direction
* Nuance - “The Maturity of Teams”
There’s of course a small nuance which is the maturity of your teams. Many product managers / leaders tend to stick to Hi-Fi mocks, a brand of spoon-feeding so as to get the young designers aligned with the outputs, ensuring that efforts are channelized in the right direction. The reasoning here is often directed at deliveries & timelines / deadlines.
When that may be so & could also make perfect sense to most PMs / design leaders who may find themselves at odds with aligning that freshly onboarded designer (new joiner) onto the tasks ensuring they extract the necessary quantum of work from them making them look potent enough so as to keep the productivity of team up & above average & ensuring they are comfortable & gel fast with the whole workflow. Well, when that’s understandable that’s also where a leader’s mettle could be thoroughly put to the sword & tested. Are you as a leader, thinking only the short-term / only the long-term / are you able to find middle-ground to balance it all as perfectly?