I had an interesting conversation the other day with an information architect regarding the use of greeking/lorem ipsum in Web design wireframes (yes, I know it’s actually Latin). As a content strategist, I was arguing in favor of using real client content and he was arguing in favor of using almost no content.
The funny thing is, once we talked it through, we finally came to agreement on almost all issues. The sticking point turned out to be our internal idea of what a wireframe is used for. He was focused on using a wireframe to communicate functionality to an application development team while I was using thinking about using a wireframe to communicate the implications of various design decisions to stakeholders. Two very different uses and two very different audiences.
We agreed that the higher the fidelity of the wireframe, them more it needs real, representative content.
His argument against real content was that stakeholders can be distracted by it and not focus on the design. My response was that I though having that distraction was a good thing. If a content strategist has been involved in the project and written wireframe content that fully represents final copy based on what he knows, then that needs to be verified.
If the content used is not very close to what the stakeholders envision the final content to be, then the design may have to change. In the end, the information needs to fit the architecture.
Just as in war where, “no plan of operations extends with any certainty beyond the first contact with the main hostile force,” (Helmuth von Moltke) most wireframes need to be adjusted after the design is filled with real content for the first time.
The sooner we have the design come into contact with real content, the quicker we can react to misunderstandings, un-managed expectations, and design challenges that are now informed by reality, not assumptions.
The funny thing is, once we talked it through, we finally came to agreement on almost all issues. The sticking point turned out to be our internal idea of what a wireframe is used for. He was focused on using a wireframe to communicate functionality to an application development team while I was using thinking about using a wireframe to communicate the implications of various design decisions to stakeholders. Two very different uses and two very different audiences.
We agreed that the higher the fidelity of the wireframe, them more it needs real, representative content.
His argument against real content was that stakeholders can be distracted by it and not focus on the design. My response was that I though having that distraction was a good thing. If a content strategist has been involved in the project and written wireframe content that fully represents final copy based on what he knows, then that needs to be verified.
If the content used is not very close to what the stakeholders envision the final content to be, then the design may have to change. In the end, the information needs to fit the architecture.
Just as in war where, “no plan of operations extends with any certainty beyond the first contact with the main hostile force,” (Helmuth von Moltke) most wireframes need to be adjusted after the design is filled with real content for the first time.
The sooner we have the design come into contact with real content, the quicker we can react to misunderstandings, un-managed expectations, and design challenges that are now informed by reality, not assumptions.
Posts
No comments:
Post a Comment