Design the missing link

A few days ago I read three interesting quotes:

The first one is by Antoine De Saint-Exupery: 

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

The second is by Peter Morville: 

“The design of good houses requires an understanding of both the construction materials and the behavior of real humans.”

And the third is by Charles Eames: 

“The details are not the details. They make the design.” 

I know that every one of us heard the first sentence again and again during our life – but more often we fail – maybe it’s why because our client, the topic, the context or or or force us to do things we should do … or shouldn’t do. During my years as an information architect and in the last few years as an experience planner, I’ve worked with lots of different development clients, agencies and teams. From big companies to small startups, the interactions between me, the one who is responsible for joy and success of use, and developers have been pretty consistent. We explored and run through what interactions and features are possible given our timeframe and resources. We talked about edge cases and clarify how specific interactions should work. We pondered on product strategy, information architecture, target audience, front-end technologies, and more. We also frequently encounter the same issue: the need to consider what’s not there. The approach the team got there was constantly the similar. The team and I planed and designed to consider and reflect on user goals, business requirements, and technical considerations to create an application, device and interface and all the requirements which are often unseen and unconsidered stand in the back. In best case - these inventions and outcomes gets evaluated and finally documented. For the reason that I mainly work with fast-paced agencies, I often have to produce my documentation under extreme and tight timelines. This means there is not a lot of time for creating detailed design specifications. This is very disappointing, because I firmly believe that a good documentation for the most projects is on the long term cheaper, smarter and last but not least quicker. I think that this is extremely important. For me this particular point is of special importance. Nor is there a chance for me to provide prototypes or templates for every part of an application.

Well – Yes – often it’s not necessary to define each and every part down to the smallest part of the app - like error messages and phrases – Yes – You’re right – BUT bad phrases and error messages can the reason for failed or ineffective services and applications.

Supportive error messages are the first step toward getting troubled users and customers back on track. Keep text brief and easy to understand. Avoid confusing terms and unfamiliar language when helping users overcome crisis points. So I turn over mock-ups and workflows - in the appearance of excel-sheets, stories or task diagrams - to the development team. 

What I commonly get back is a major part of the design / of the character and or nature of the application. By major part of the design I mean that all of the content, context, features, and functions are planned, and they are ready to transfer these elements into visual design. Well – and then … what’s the missing link / the missing item? What’s missing is what’s undiscovered, unmentioned, and hidden: position, arrangement, appearance and - ehmm - what was that again? – ah Yes … and the whitespace. The visual designers and the development teams are in charge for putting content, functions and interactive elements into a product. Blank space / whitespace is neither content nor functions. Therefore, it is not a request, demand and or requirement. For a visual designer, however, it’s often just as significant and essential as the areas for content and functions. Visual designers use a lot of time arranging whitespace to allow effective scanning of elements. I also use a lot of time optimizing and improving alignment and padding to establish a user interface with well-designed utility and usability. I make use of both of these principles of arrangement and classification to lead the user through the content and functions on a page or a form. I use these principles to communicate what’s most important, what’s related, and what needs attention. For designers, these are key requirements of effective communication – and that’s proved. I would be so pleased to see more developers bring the skills and craft they apply to the construction of the visible to the construction of the invisible: padding and alignment. Once they learn to look for these things in a design specification or mock-up, they’ll have a better sense of the designer’s intent. A shared understanding of what’s being built - whether visible or invisible—goes a long way toward making products that our users can understand. And it’s necessary that we all get a common understanding of the relationship of expectation, experience, knowledge, scanability and findability.