How We Design

How We Design

Overview

ADG is a design and development firm, but we are included in projects at various points. We’re often engaged from early strategy & brainstorming all the way through deployment and marketing, but not always. You can think of the stages below as a la carte options.


Requirements

The venerable 100-page requirements document is fortunately (almost) a thing of the past. Crafting a detailed requirements document often meant “designing” an application before any real design techniques were involved – creating a product a priori, in the head.

While requirements are still appropriate for objective characteristics – specific outcomes, specific interfaces and API’s, concrete benchmarks – an early-stage document is not good for subjective characteristics; in other words, anything related to design really.

Requirements should be about what must be done, not necessarily how. That’s where creative comes in – not just in design, but also development.

ADG is most often not involved in compiling the requirements for a project – it’s usually an input for us.


Strategy & Brainstorming

Every project has to start somewhere and that best place is always brainstorming with – in our opinion – the simplest tools you can use: paper, pens, whiteboards, people. Too often over-enthusiastic teams rush to get ideas “on-screen”.

app brainstorming

app brainstorming

The cost of changes to a product or application – in time, money, angst – tend to rise non-linearly as you move through a typical development process. I.e. any given change will typically be much more expensive if attempted in wireframes than brainstorming, or actual code than wireframes.

Figuring out a strategy, and conducting effective brainstorming, is not just a matter of putting people in a room with pens and whiteboards. The best sessions are more often led by someone who can balance entertaining crazy ideas with what can pragmatically be executed over the long haul, given a project’s budget, objectives, and timeframe.

We’re pretty good at this. There are techniques for successful brainstorming that really work. And we’re often brought in just to get a team focused on a direction with enthusiasm and a real plan.


Shoot for the moon, land on the roof.

Preliminary Design & Mockups

This is the step that too often gets skipped. Brainstorming – done right – gets teams excited – so the tendency is to go right into detailed design. The problem is that without a “big picture” view of the product being developed – something you can reference literally over the course of the larger project – you don’t really have a “destination”.

At a prior company we had a motto “Shoot for the moon, land on the roof.” It’s the nature of application development that constraints will inevitably compromise the original vision over time: money and time run low, unforeseen technical problems arise, environmental or political conditions change. To us, the motto meant that without a really lofty, and pretty clear, optimum goal – the moon – you will inevitably land, well, anywhere. But with a target – albeit aggressive – you can at least end up as far as possible in that direction.

rough comp

rough comp

If you’ve worked in a corporate environment, you’ve probably been in the room where – after six months of work – the big project is presented to the big sponsor and he or she says “that’s not what I envisioned”.

We think that before technical design begins it’s important to try to get all stakeholders “seeing” the same thing. The traditional Requirements Document can’t do this. In most cases there are important stakeholders outside of the core design and dev team that can’t evaluate a requirements document or – at best – will scan the document (to “approve” it) but develop a picture in their head of what they expect to see down the road when the project is finished. A picture that is usually dramatically different than what is eventually delivered – even if the product technically addresses the “requirements”.

There are a number of tools for making a product “tangible” earlier rather than later – that can help plant the same vision (the moon) in the entire team’s head: from designers to developers to executives and investors.

Here are the ones we use, in increasing order of “resolution” or sophistication:

Static Comps & Mockups

In the theme of “start with low resolution / simple tools and work up”, static comps – screens mocked up in Photoshop, layouts mocked up in Keynote, etc. – can start to outline a product’s look, feel and function. We were one of the earliest shops to aggressively adopt Keynote as a rapid design and prototyping tool. We will often use a combination of Photoshop and Keynote to rough out application screens that can be reviewed online, printed, shared via PDF and more.

Interactive and On-Device Comps

Static comps are pretty universally used, but if used exclusively a lot of design potential goes unconsidered in this era of hand-held devices and increasingly multi-touch, gestural interfaces. Design truly is now a combination of visual and interactive ideas.

on-device demo

on-device demo

To that end, we have developed techniques for outputting Keynote and Photoshop content into screen images that can be accessed or side-loaded directly to representative target devices for semi-functional tap-through demos. This is invaluable for thinking through user tasks, gauging tap targets, and testing font and image resolution.

Even technically unsophisticated stakeholders (e.g. marketing execs) have benefited from this kind of approach. We have frequently developed very early stage simulations of smartphone or tablet applications in HTML5 that are posted to private URL’s and then accessed directly by the actual target devices. Peripheral stakeholders are usually delighted to have a device handed to them with even rough simulations of the imagined app – an interactive comp that they can literally carry around and play with.

Visualization

When we talk about visualization we’re talking about product simulations that are both higher resolution, in terms of finish quality, but usually lower in terms of interactivity: i.e. video and high-end 2D or 3D animation. Product visualization tries to answer questions like:

  • What does the finished product look like?
  • Will this be competitive in the marketplace?
  • What does the product look like in context (e.g. on the target device, in a typical usage scenario)?
  • How is the product branded? Does it fit with the parent brand / product offerings?
visualization

visualization

For product visualizations we typically start with high-resolution screen comps of products which are then brought into After Effects for compositing and animation. The end product is usually a short video that can be used for internal approval and feedback, socializing a project to stakeholders, attracting support or outright funding, and even early stage marketing. ADG visualizations have been used for everything from a consistent reference tool for the design and development teams all the way to product announcements and launches at major conferences.

The emphasis with visualization efforts is on emotion. The best executions provide inspiration, direction and – done best – a glimpse at a magical future state. Without actually building the product.


Every click is a wish …

Wireframes & Prototyping

With a vision in hand (often quite literally) the production phase of design and development still relies on the detailed blueprint. Translating the rough brainstorming, design comp and simulation assets into detailed wireframes and production assets is a tedious effort and usually comprises the bulk of any application effort. We will frequently run to 50 or a 100 versions of the master wireframe document for a reasonably complex application. The amount of rework however is inversely proportional to the amount of prior phase (e.g. requirements, brainstorming, mock-up) work performed: the objective of those stages is to ferret out problem approaches and dead-ends before the time (and money) intensive phase of creating the detailed specifications.

The wireframe specifications have to address basically every “what if” in an application. Every keystroke, gesture, action, etc. has to obviously be documented. And the creative process is far from over at this stage. Many applications fail or succeed at the detail level – the fit and finish. We use the phrase “every click is a wish” a lot around here, which means to us that the perceived success of the application depends on how well we have predicted the users intention, in whatever they do. The design objective should be to delight the user by anticipating correctly – even when they’re not even quite sure what something “does”.

wireframe document

wireframe document

Our wireframe documents, and related media asset files, have been refined over many projects and years. To us the highest praise we can receive is not only from our executive clients, but rather the tactical development and production teams we work with: those folks who actually have to use our documents on a day to day basis.

90% of our asset production is done in Photoshop (we can digress for hours on the Photoshop vs. Fireworks vs. Illustrator argument, but won’t here). 99% of our wireframe documents are produced in Keynote (another bloggable topic for later). Both master documents are carefully version-controlled and tied to each other via reference layer comps for ease of reference and asset extraction / creation, and to increase asset resolution and accuracy over the course of the project.

Further, we deliver all assets, and monitor all feedback and discussion, via our Basecamp site, wherein all projects and assets are tracked separately and privately, and easily referenced by clients 24×7.


Asset Production & Development

Well after wireframes and specifications have largely been locked down, asset production in support of development continues. In many projects we have seen a disconnect between the technical specification documents and the production assets that introduce a huge amount of confusion and rework. We use a simple process of keying our wireframe documents to our master asset files (typically Photoshop) via carefully documented layer comp settings and individual asset definition. The combination results in high to perfect consistency of fonts, faces, color, shading, layout integrity, matting and much more.

ADG Basecamp site

ADG Basecamp site

Consumer sophistication – especially with regard to mobile apps – is creating an environment where user interface fit and finish – not just static graphic detail, but motion, animation, tempo, audio and more – are critical to success. We work hard on the details: not just focusing on how great the final product looks, but also how carefully crafted the interface is from a production and layout perspective. Grid layouts rule, but increasingly we’re also focused on so-called “responsive” interfaces that well accommodate different resolutions, screen aspect ratios, etc. (For example, if you are viewing this website on a desktop browser, try scaling the window from wide to narrow and see what happens – that’s what we mean by “responsive”.)

We post our assets in development-friendly ways – typically via our Basecamp site – where they are version controlled, easily searched, safely archived, and available 24×7. They can also be viewed easily by other stakeholders (e.g. brand police) as needed.


QA & Testing

While ADG does not conduct formal user, performance or requirements testing, we’re often involved in the process. This is interestingly another place where we have been called in to rapidly prototype alternative fixes (an early phase task) when an issue has been discovered late in a development process from user testing: we’ve been able to quickly provide options that can be tested on users and then integrated without stepping back too far in the process.

On the other hand, when we have been responsible for design and specification documents, we are typically contracted to periodically test builds of applications and check for deviation from spec – both functionally and visually. Again, the feedback documents we provide back to development teams are explicit, visual and tied again back to asset documents that make correction straightforward.


Deployment & Marketing

intelevision ad

intelevision ad

As mentioned above, our visualization assets have frequently been used for socialization, evangelizing and sometimes even publicly marketing products (e.g. one piece for Verizon was used in the Chief Marketing Officer’s keynote presentation at their last major developer’s conference).

In addition, we do on-going design and production work for marketing groups on a regular basis. We have long-term retainers with some clients who have come to depend on us for our consistent quick-turn production ability – for reasonable rates.

Product photography, compositing and layout, video production and editing, and light 3D and 2D animation are all capabilities in house that our clients regularly call in for situations where their above-the-line agencies do not have capabilities, or out-source to inconsistent third parties.


Test Drive ADG

Clients have hired us for everything outlined above, a la carte capabilities as needed for a project, and even brought us in and out of projects as episodic guns for hire. Naturally, this also pretty much describes how we develop our own products. And as we learn from our own entrepreneurial work – and our mistakes – we refine our process continually. To your benefit.

Contact ADGGive us a call. We’re easy to work with.


Words

When we're fed up with Photoshop and After Effects, we write stuff.

iOS Animated

We decided to see what kind of assets – icons, images, sounds – ship as a part of the iOS operating system on a...

iPhone Auxiliary Screen Concept

Pre-visualization / concept comps for an iPhone auxiliary screen. Use cases are for remote monitoring / light interaction with iPhone (via Bluetooth or...

Earned Attention

Earned Attention is a new book / eBook out by Klaas Weima that includes interviews with 50 “visionaries” in...