Large projects, tight budgets and deadlines, so on, may render out certain parts and segments to come. Parts can run parallel, say having a universal design-set developed simultaneous to wireframe-creation which benefits from a total lack of visual input. Others may require everything and everyone to halt. Where to start setting up production the most appropriate way?

Projects vary, teams vary, and so does the approach. At the very least revising and segmenting the work will in planning.

The broad wires from before have not just helped creating the more expanded and encompassing (and likely more intuitive and seamless-) solution, it has helped in other ways as well. They will expand in definition later, the reason for initial broadness are plenty:

• Revisions

  “Broadness documents the project-wide needs, which are essential in order to design. Needs previously not obvious (and thus not included initially) are apparent, and can thus be included where applicable. Needs included initially, but now obviously redundant, can be omitted.

• Segmentation

  The clearer overview allows for accurate segmentation and restructure of the whole experience. Parts and order can be changed or moved to create a more seamless flow perhaps not obvious in one of our initial ideations.

• Distribution

  Broadness documents project-wide needs, but does not necessarily document the actual layout, which I am now able to segment then seed/distribute better across team-members - without disruption of consistency thanks to the encompassing approach

Speaking off...

When the amount of work has been revised and segmented it’s easy to build a roadmap and pick a suitable approach in team structure.

There are many, but the keyword is suitable to project. I couldn’t possibly pick one generic one.
I won’t focus on project management now, but a short note:

Agile and the likes are still popular., especially large project with larger teams.
But it’s not for everyone every time. Large teams, or simply companies with an overall large staff, commonly run into the unfortunate over-communication in the various forms.

Small teams of a few dedicated key persons is something I prefer overall, having yielded the best results. Communication and ownership are simple, and with a lack of obtrusive organization it’s easy to focus on the tasks at hand. The lump of production can sometimes be automated.

Arguably the environment a product is to be used in is something that is fairly obvious from the start. A “responsive site”, as an example, can be decoded to “A site that conforms to  both traditional computer screens and mobile devices” and most people are happy with that. Fair enough. The second step to consider is what that encompasses. Should the content layout be replaced, or adjusted, depending on what fetches that data. Another set of decoding is needed here. And, thanks to my information design education, I like to decode it about one click further. Namely, what are the dynamics of the environment.

An example of studying your tactile input and manipulation devices, i.e. your hands, starts by looking at where they’re positioned in relation to a number of factors.

Where, what and how we use all of our bodies, not just the eyes, matters to a point in my design.

While there are hundreds (if not more) wireframing software out there I’d like to mention my use of wires in the broader sense. I don’t wire pages of the bat, I wire the whole experience first. Consider the holistic approach mentioned earlier.

This might sound like something a good producer would do, but I don’t mean it in the sense of defining includables. It’s about combing out sets of different information needed to start the design process. Be it a personal physical product in a dynamic setting or an interactive experience serving millions simultaneously.

To share a common scenario:

Our natural urge is to start with A then move on to B.

Perhaps with wires we feel like we’d prioritize “main” as a starting-point.

We then start mapping out “main”, and the more we work on main we branch out to to the remaining corners. Say, a site. Top page then dictate subsets.

...However

The point of combing wires / broad wires are to capture the whole project before dictating main. Some of the bigger reasons as to why I prefer this (seemingly slower) approach:

Our solution ideas are made. Our bottomless vanity impulses often have us wanting to try out things graphically to reach a point which looks good and resonate with this idea.

I find this approach ultimately time-consuming and somewhat wasteful (still fun though).

Instead, considering a theoretical reason before application is practical: it’s visual ideas without graphic interference. It saves myself from common pitfalls, loops, of trying to mend until right.

At this point styles may not be of consideration. I personally don’t let try not to let specific graphic come into mind before ideas of functionality are mapped out. Keeping in mind the past attitude toward ideas.

Idea boards, not to be confused with moodboards (or even ol’ faithful; brainstorming), help tie together theoretical ideas. The process is the same. The board aid the previous starting slate.

I’ve mentioned ways where a project scope extends due to strategic reasons, making sure we are not just dropping off work and be done with it.
In tandem to the expanding design solution part of the scope might get lost, forgotten or simply bulldozed. Or the connection to our initial ideas might get obscured or muddled. To reclaim consistency in both quality and connections I take a few steps back through frequent revisits to our composed idea for assurance. Our idea package and finalization are simple parts to (re) view.

Also, as our design expands so does the need for resources. Planning, again, in terms of schedule forecasting is essential. To combat overtime, running budgets and unnecessary work. Even new parts of the project, which are parts not given enough thoughts since they aren’t fully considered- or thought out just yet because our devised solution takes priority.

IOW:

With the researched backed design solution defined, and the work this far given substantial structure to our ideas, what remains before producing the visual representation is finalizing the functions.

“Functions” may seem like an online- or say software specific part. But design, any design, carry function. Take a photo for instance, where specific motives are agent of function designed to to trigger responses. Angles can functions that can lead eyes to focus points.

Getting back to online, game or software specific parts, getting further into our wireframes will greatly in structuring function.

As previously mentioned I keep my wires broad, at least initially, until they capture all functions of our solution.

The trickle down starts with holder-sets (the kind that lets you share elements throughout your wires, and update a master set), which are incredibly important for me to maintain while broad stroking the site.

Especially with system that are designed to work with millions of users, millions of actions and transactions, often in parallels and across servers.

Details are, to everyone else’s hair pulling annoyment, saved for last. Agile methodist beware (don’t worry, I can adjust if really needed).

This plays to the approach I have with planning, and making it consistently right as suppose to backtrack and correct preferred for fast output. Because backtracked corrections rip tears that take an equal pay in the amount of total time. Trading rips for faster production through Agile would be a fair tradeoff were it not for one additional disadvantage that comes with it: possible inconsistency. Patched solutions often turns out obvious, and in the grander sense then detrimental to quality.

Ok, hush, back to broad wires trickling down to regular wires.

For example, maybe we don’t need a loading percentage bar between two sections. Because a loading interface requires resources too. Perhaps the scenario means that a load is required but the amount minuscule which means a simple transition would do, rather than a load screen. Because hey, load screens ARE proven annoying. Perhaps baking in preloaded resources for transitions, instead of load resources, are better than what was initially planned.

For example. the proposed options in a menu-set have expanded. Suddenly the stay menu at the easily reached bottom part of our game screen can’t house all options. Easily solution: drop down options. Which is not so easy, because drop downs are universally expected in the top corner - and that means a whole redesign is needed. With planning, and the all-encompassing view, this could have been predicted. If not, keeping it broad have left me with room to more easily adjust.

Once laid out properly, with functionality baked in, people gets to test the product. A relatively rapid way to inspect the important user-flow, but also sizing, comfort, so on. And unlike pure graphical prototype I can adjust accordingly very, very easily.

At a few places, even now, wireframing have been foreign to some co-workers I have worked with. The benefits have been hard to see, at first, but after some convincing and education have pulled through. But not flawlessly. Time, most often, have been the issues. Seeing worth in good planning, perhaps because of accepting rips/blockage/rework as the norm, have sadly been all too common. Other problems have been coworkers not understanding the wireframing technical concept, insisted on things like exact measures.

To summarize:

Wires are semi-flexible. They are there to frame- then support the graphical solutions to the problem.

While slow to initiate the graphic production, like my holistic approach in general, they ultimately speed up the process. Resulting in faster total turnaround time and proper consistency to name a few benefits, not to mention planning.

Finally getting into vanity the creative part.

With solution functionality defined, and visual functionality prepared, the process to produce a visual profile is easy and straightforward. Tools and approach may vary but the ultimate purpose is the same: create a visual recipe that reflects and carry the solution.

They're not that different, and they are not solely for the produced design but for your production as well:

The definition could almost get even further simplified: one’s set, the other isn’t.

But that’s probably pushing it too far.

Hopefully I’ve covered expectation and reception in the many, various, previously mentioned tests. Which should have given me information enough to work up a graphical theory. Adding a proper moodboard to it and I’m confidently ready a profile is born.

The reason I bring in styleguide now is because it can be treated in different ways.

While many of us was used to seeing it as something created at the end of a project for future visual consistency if and when someone else touched our creation, it was when all exploration was over and a final version had been drafted.

The other way is early on producing a style guide to act as an evolving set to be applied in tandem with the wireframe creation. Perhaps best suited for larger projects and teams with dedicated specialists.

Going over the project as a whole allows me to comb out the needs for every part, which in turn I can distill into a common set of elements.

By knowing the essential needs I create a master set of common elements by having a look at their true functions, and importantly, simplify it from there knowing the needs. The less is always more. If there is one place to go overboard in simplicity, (and not a very common reaction to “go creative” with it), this is it. I need room for the less common elements, and the less distraction (Simplicity³ again) the more room I have for deviances.

Deviants from this system will be had, either in shape or function, but need to share appearance and operation for consistency to minimize focus loss. Long way of saying “keep it consistent to not confuse people”.

…but not always.

Breaking out of the master set, created inconsistency, can be an efficient way to create focus should the situation require it.

An example I’ve brought up at university: the stop sign.

Most designers will have a set of prefered tools and methods to produce assets.

Let’s talk methods and general direction of production. Specifically the ones I device which saves time for the whole team, allowing me (and others) to focus on other things than just production.

Automation shaves off time from production. As the tools and processes evolve it’s not just for rudimentary tasks anymore.

I like to think that I’ve evolved with it, and now it’s so encompassing that I include automation, or at least automated processes, to almost every single project that I am involved with.

It helps me, and the team, regain hours and put focus back where it’s needed.

Some examples ahead.

With a functional wire-frame in place (LINK), or the graphics (LINK?), and a budget that allows, user testing is magic. I, much like most, get tunnel-vision or are generally suppable to believing we know how xyz think (especially with the fodder we’ve been given LINK to How customers think). User-testing reveals things. Like how minds change, even though our needs change at completely different speeds.

An additional reason I prefer actual user-tests that corrects and strengthens your solution, besides getting paid for a chance to put people in boxes, is the impact it have with client proposals.

On the flip-side there are reasons where I’d advise against dictating by results from user testing.

- Strike this, because it’s pre testing (before a product is half done) Some tv-shows (LINK to Homers car) are not to far off on this.

Feedback based input, particularly those based on personal taste, can be very misleading (Link to J game producers) and devastating if it carries ultimate weight. Sometime users don’t really know what they want. Sometimes they expect things that aren’t really beneficial, or in the reverse, don’t expect things and reject what is beneficial.

A couple of things to combat this:

- Avoid leading testing

- Recognizing patterns across user feedback

- …and following up / understanding that particular feedback. Try this on: “I didn’t expect that” … “…but it made things easier”.

Prototyping

We are getting near alpha now. Here are a few important stops no matter what’s being prototyped. 

Testing is important and will likely be a part of the prototyping process. Throwing in additional user testing before a launch (closed, open, in any which state) is invaluable for long term benefits. Tunnelvision is a thing, spending significant time involved in a project can blind creators of both obscure or obvious misses.

With the substantial research done before testing shouldn’t yield results that warrant complete re-do’s. Things should be legit. Never say never though, clean slates are a thing.

I kill my babies-darlings if need be. No problem. I don’t get attached to the visuals, even if they might have taken me a considerable amount of time/sweat/tears, because I’m not attached to visuals. I am, however, attached to ideas. Especially, if you’ve read this far through my process, when they are backed by research. Changes, modifications, honing are all well, but unless there’s substantial and objective proof of alternatives being more efficient towards a specific solution I don’t like to budge. From my experience alternatives to what’s been clearly thought out have in the majority of the cases sprung from project fatigue resulting in solutions patched to the surface of the problem.

Simultaneously: I’m human (surprise!). By design iteration number 12 I’ve probably lost interest too.

If it’s not project fatigue, say a client (or even in-company) request, I think it’s important to stay true to the resolve. Different solutions within a solution pulls in different directions, making the overall product thrown together at best. And in the end that sort of delivery doesn’t just hurt the client and her customers, but also oneself and your company.

Checkoffs

Should the user-testing have helped, with usage and the graphical palette, there’s undeniable research to bring for a client checkoff if not already done to remain on target. If not, (say if there was no room for a rest, which is a bit of a common myth), putting solutions in scenarios help towards that same end.

Sidenote: check-offs can be client expected and defined. If so, terms and includes should have been structured in the earlier planning.

Similar to the pitch, but with more safety from the investment of both parties, dismissal because of lack of communication can be rectified by re-education. Or reminders. Or, thanks to the slight safe advantage - redone. However I am still on the fence about veering away from the resolve.

Client input is good, they’re paying of course. But the ultimate check-off, the one that actually means something, is the clients clients. At times the opinions between the two, the clients and clients clients, collide. Given a pick, seeing how I’m a designer, I design - which means I do things by purpose - and as such the service shall always be that towards the whomever uses the product in the end.

Unlike the client check-off/review, the client-client review do come with a few clauses and complications. Such as it being without a prerequisite. Unlike the almighty payers of my bills, there is to be no ask, no preparation, no set up in advance for client-client reviews. The feedback is more genuine in that regard. But this same, honest feedback is also reactionary. Without preparation there can be surprises, and with surprises there can be skewed feedback.

On top of that: customer psychology. It tends to lend itself to what one is suppose to believe, which often roots itself in most common denominator.

Take the first iPhone launch in Japan. The majority of all business magazines predicted a flop because “it wouldn’t resonate with the Japanese consumer”. Heh.

Of course there’s a thousand and one more variables, and some where a product can test perfectly across the full scope yet still fail because of external or additional factors.

Covered previously are the mid-progress checkups. In a way user testing is just that - verifying that the backed devised solution matches with the produced output.

Since mid-progress wouldn’t necessarily include enough of finalized function or content, tests through check-offs may be premature and as such I’ve separated the two.

Additionally, tests may be conducted before or after checkoffs. It’s really up to the format, nature and environment of the produce the solution require. Things vary, as I annoyingly keep regurgitating.

Project scope allowing: a round of Q&A and human/device compatibility checked off before testing generates better results faster.

Quality Assurance isn't just testing smooth tech. Or smooth operation. Or how the package tie together. It’s all of the above plus the experience. Things can be smooth and walk flawlessly, but without the important experience part we’re in Nielsen Norman group territory. I do love the 90s, but not all of it. Function is king indeed, but never perfect without form.

Compatibility

With complete wires behind us, and all functionality in places of easy and expected access, it’s easy to assume good human compatibility.

...and it would be true. But a times only because we humans are adaptable to almost anything.

User testing before has the examples where common acceptance is beneficially trumped by things like ergonomy.

Example: that thing again.

There are additional factors to consider as well, many that are often overlooked when shadowed by common acceptance or common rationale. By both designer and user/receiver. Like user environments and culture. Some examples:

Culture rationale location A: “people don’t want to be bothered, especially by ads, so we need to keep things short to achieve the ever short and fickle attention span one have”.

Culture rationale location B: “people want to be distracted, so we need to keep things interesting and encompassing to retain the attention span”.

Placement rationale trickery. Reading is hard from an angle but graphic isn’t. Save reading for centerview, carry it through with graphics on the sides.

I need relevant information while driving, but my eyes need to be on my surrounding.

Solution: automatically seeded- and switched information shaped for peripheral absorbtion.

That’s not to say common acceptance is wrong. On the contrary, expectancy is the greater denominator. But I always try to repeat a few rounds of common acceptance/rationale bashing if needed and warranted. May look silly and uninformed, or make me look dumb, but these are the things we must do. People are not rational, which should be to no surprise to anyone.

Tied to pre-launch but with its contingency planning aside.

During the process I’ve drafted up a few preparatory steps to accommodate a post launch strategy. The reason have not been to milk a client, I promise I’m not particularly sinister.

...afayk.

In my experience the most effective solutions usually include long term strategies in one way or the other. Strategies that continually yield results and benefits over time. Some results being directly measurable and quantifiable, some less so but nevertheless beneficial.

Investing in good design pays off, and a sound strategy with proper follow-through/follow-ups even more so.

Still lingering: the prominence of incomplete post-launch strategies.

For starters: in what regards have frames been drawn up to have a produced and implemented solution simmer? Something new doesn’t necessarily market itself on the account of being new.

Worthy disclaimer: new marketing strategy doesn’t necessarily sell a product should the product itself be faulty.

How to build further on a solution after a successful launch? Examining the results of a designed solution post launch might better shape the things to come, but with all the testing this far a general plan should be so simple to draw up it should be a requirement.

Example: Semi automated batch banner creation to keep game interesting