Wireframes are schematics or blueprints – a way to show clarity of purpose and function, showing quality of being easily seen or expressed, remembered, understood, etc.. And it’s up to you how schematic or how precise it has to be.
As architect I worked with various deliverables and so I do now as information architect and user experience designer. 7 years ago I published a flow / overview of possible deliverables within the design process



If I think about granularity of wireframes I distinguish various forms and levels.

Roughly speaking there are 4 categories …

  • High fidelity wireframes
  • Annotated wireframes (valuable to clarify function and interactions)
  • Collaborative wireframes ( team produces )
  • Hand drawn wireframes (early sketches)

First the most detailed is for sure a coded wireframe – these types of “coded wireframes” are becoming more and more the standard of practice thanks to prototyping tools. Though these wireframes are the most realistic and can show the functionality of an app, the time to create such a one is much increased.

This article will focus on a wireframe which is a non-pictorial version – a textual wireframe.
And this textual wireframe might be more useful than ever in our ‘responsible design world’.
This textual wireframe I will describe in detail is often also called page description diagram or as abbreviation PDD. It’s very simple and easy deliverable for documenting components without specifying layout. And it’s useful to define and discuss the prioritization of content and features.
In an early and plain version the page description diagram lists the elements of the UI as labels or short description,

PDP Page description Page 1

later you can use or add prose, as you have in your functional specification, or you link to the functional specification. Sometimes I added also sketches or layout snippet e.g. date viewer (especially if I reuse elements or work on a redesign).

PDP Page description Page 2

The elements are arranged on the wireframe in priority order. Usually I define the horizontal axis of the diagram as the element priority. Thus, content areas described on the left side of the wireframe are higher priority than those on the right side of the wireframe.

With this approach, the wireframe represented the two main issues: priority and content. And the real big benefit of this deliverable is that you can define and discuss UI elements with the team or your client without losing the discussion by talking about layout and brand attributes.
And later when you include layout snippet it helps your client visualize the interactivity, but did not lock the designer into any particular approach. Your conversations with the team or client focused on the nature of the content and functionality and the relative priority of the page contents.

Regarding the priorities, in general I work with 5 priorities (Overall, High, Medium, Low, Context) but often it’s useful to start or to work with 3 priorities (High, Medium, Low). These priorities are key to both defining the layout of the elements and encoding the users’ needs, so they need to be both consistent and clear.


  • High Priority: These elements are vital to understand and reaching the goal of the UI
  • Medium Priority: The UI should include these elements e.g. to get additional understanding and to function well and serve for the majority of a user’s needs.
  • Low Priority: These elements are useful, but not vital to understand and reaching the goal of the UI


The more we talk about responsive design and addressing platform-specific or in other words situational appropriate content and options the more useful might be the textual / page description diagram (PDD) more than ever.
PDDs in combination with well-designed responsive grid system (I will write another article about responsive grid systems as soon as I have time) will reduce the number of needed wireframe designs.

Not logged in