Tag Archives: design

Application design is like recording a cover version of a song

Let’s face it. 99% of our design effort is spent on developing applications that already exist in some form or another. We work continuously to build a better mousetrap, not invent some fundamentally unique and novel way to catch rodents.

This is not to belittle the difference we make but to recognise we stand on existing shoulders. Or if we don’t, that our users do and will judge our efforts (fairly or unfairly) against those pre-existing expectations about what our [insert class of application here] application should look and feel like.

This need to try and marry those conflicting needs of “identifying with the original” and “being different” led me to compare the whole application design issue with music, in particular cover versions. Here’s another area where you are developing something that has both to be distinctive (and your own) while still recognising the essence of what came before.

what makes a good cover?

So what makes a good cover version? And what can that tell us about application development? Probably two conflicting goals:

  1. be true to the original, but
  2. add your own individuality.

Also hidden before the above two is “choose a good song to start with”.  For software development that means picking an application that people are going to want to “listen” to.  Your application version of a cover of the Macarena might not get the audience you would like, no matter how hard you work.

Be true
At some level each song (and therefore each application) has an underlying essence. Any to-do list manager needs to cover fundamentals like adding/removing items from a list. Any photo library needs to be able to add tags to photos to classify them, etc. The trick is to use the concept of the cover song to uncover what is the essential for your new version. What needs to exist for your users to recognise this as one of the type? And importantly for them not to dismiss it for missing something fundamental?

In looking for original applications you can start to diverge from the whole “application = cover song” metaphor, since with applications it is possible for what is considered the original to change. In music the original version of Tainted Love will always be by Gloria Jones, nomatter how many people have (a) never heard of it or (b) prefer Soft Cell’s version anyway. With applications what is considered original can vary, with first versions disappearing from view (Visicalc anyone?). In fact it’s probably more accurate to talk less of the original application and instead talk of the definitive or archetype. And recognise that it can change. For example 5 years ago the original/definitive social website you’d need to study would have been mySpace. Now it’s Facebook. Unless you’re in Brazil where it’s Orkut (thanks Oxyweb).

In some domains, there might not be an obvious original. In such cases the essence may be determined by reviewing multiple examples and drawing out the commonalities. And in that regard you’re moving towards the same approach as per the backs of most software packages, each with their feature lists comparing themselves (favourably of course) with the competitors.

Be individual

So once you’ve determined your original, and confirmed what features/functions are needed to be true to that original, now is the time to add your own spin. To add your personal creativity. To make the cover version.

And like musicians you’ll play to your strengths. In the same way that a Metallica cover of White Christmas is likely to include a few guitars, so a cover of the to-do list manager you create will reflect your own preferences in design, usability and approach. As long as the underlying essence remains evident, go for it.

CY6532

CY6532 is the keypad code to get into the toilet block at Jindabyne campsite. I tell you this not because I think you’re all going to rush there and steal a shower. It’s because having stayed there for a weekend to go skiing I now have that number lodged in my brain. And I resent it. I resent the laziness of the design solution that imposes this overhead on me.

I’m sure cognitive scientists will tell me that there is no finite limit on brain capacity (since in this instance we’re not talking short term memory with its estimated 7+/-2 limit). But rationally or otherwise I cannot help feeling that my having to remember that code has meant some other useful snippet of information has been relegated to the dark corners of my brain. Or dropped out altogether. And for what? I’ve left the campsite now. I won’t be returning for a year at least. How much longer am I going to ‘know’ CY6532?

All the time as designers we have an option that transfers the awkwardness of a design from us to our users. We impose on them some – we think insignificant – overhead (just remember this code) rather than coming up with something smarter (swipe card/bracelet? Door unlocked?). And all such impositions get wrapped up as “training issues”.

Well next time you face that decision, remember CY6532. I know I will for far too long.

Using flowcharts effectively

The old adage says that a picture is worth a 1000 words. When talking about business processes and procedures you’d have to say that’s a little on the conservative time. When done correctly a flowchart is an invaluable tool for determining and communicating how a business function is conducted. However, there’s the rub: “when done correctly”. Anyone who’s explored the available stencils in Visio knows it is very easy to complicate any flowchart.

This document collates some guidelines we put together for one project to provide a consistent and simple standard for a variety of drafters.

Note these guidelines pertain to the documenting of procedures, per the Information Mapping definition, and as distinct from processes. However generally the principles apply to any exercise to map a business function.

Shapes

  1. Use only a standard, and limited library of shapes. As a starter, most flowcharts need only the following.
    Standard shapes for procedure flowcharts

    Standard shapes for procedure flowcharts

    Add additional shapes reluctantly, and provide a key to explain their meaning.

  2. Keep shapes the same size.
  3. Use a standard, and consistent, font, background colour,shading, etc
  4. if using shading to highlight specific steps, include a key alongside/with the flowchart to explain the convention adopted.

Layout

  1. Draft the steps so that the flowchart runs vertically, top to bottom. This format is preferable because it fits the page better, both on paper or online.
  2. Centrally align all shapes, including joining arrows. This helps keep the layout clean and easy to follow.
  3. Keep a consistent spacing between shapes.
    Right and wrong way to layout flowchart steps

    Right and wrong way to layout flowchart steps

Language

  1. Write each step or decision as a command (2nd person singular).
  2. Keep the text brief and simple. Not only does it make the flowchart easy to follow, it also allows the shapes to be smaller and still fit the required content.

Decisions

  1. Phrase decision as a question answered by “Yes” or “No” only.
    Wherever possible the question should be phrased so that the “Yes” answer is the one most common, expected or otherwise “default” for the process being presented.

  2. Have only the two possible paths (yes or no) from a decision and clearly label each path as Yes or No.
  3. Organise your flowchart so that the “Yes” path continues straight down. The “No” path branches to the side (normally the right as we read left to right).
    Right and wrong way to document a decision

    Right and wrong way to document a decision

  4. Where possible continue the branched path using the same alignment (vertical, centred) as for the main path; however if space is limited you can allow the side steps to progress horizontally instead.
  5. Either layout, stagger the spacing on the main path so that arrows from the branch path rejoin the main path without needing to point up. Arrows should return horizontally or downwards.
    Organising branch steps vertically or horizontally

    Organising branch steps vertically or horizontally

  6. When aligning branch steps:
    • branch starts from the side of the decision and joins the side of the first branch step, and
    • branch rejoins the main path from the bottom of the final step into the side of the first main step that both paths repeat.

    The only exception is when the branch rejoins the main flow at a decision. Obviously the path cannot rejoin on the side as it will be confused with the decision itself. In this instance either:

    • add an additional step to rejoin to before the decision is made, or
    • have the branch path rejoin into the top of the decision diamond.
    Rejoining the main path before a decision

    Rejoining the main path before a decision

    Phases

    1. If your process has clearly identifiable phases, consider highlighting them in the process.

      Phases provide a useful organising mechanism, particularly for larger processes. They can be based on any aspect:

      • time (eg January, February)
      • location (eg in the office, on client site), or
      • status (eg pre-signoff, post sign-off)
    2. To identify and separate phases:
      • use a horizontal solid line, and
      • label every phase (add the label near the line that identifies it)
      How to specify phases

      How to specify phases

    3. Organise the layout of your flowchart to ensure all steps for a particular phase are presented above the line that designates that phase. Doing so may require leaving gaps between steps, particular when including decisions or departments (see next section).
      Organising steps to fit (in) each phase

      Organising steps to fit (in) each phase

    Note depending on your flowcharting tool you may have a function to specify phases and automatically provide the separations around which you can organise your steps.

    Responsibilities

    1. If responsibility for completing steps in your process varies between separate, identifiable individuals or groups, consider highlighting them in the process. Organising your process to reflect responsibility helps those who have a role in its completion to quickly and easily identify what steps they need to complete.
    2. To identify and separate responsibilities use vertical swimlanes:
      • organise steps into separate vertical columns, one column for each person, department, etc
      • add vertical lines between columns to identify the edges of each swimlane, and
      • label each swimlane clearly at the top
    3. As for phases you may need to be flexible in layout (adding extra space for example) to ensure all steps for a particular group are grouped in the correct swimlane.
    4. Try not to over-separate your steps into too many columns. Using swimlanes will make your flowchart wider, which has major issues when trying to display on an A4 page, or a computer screen. Consider either “rolling up” into larger groups of responsibility or moving steps for one group to a separate flowchart.
    5. Follow the same guidelines/preferences for joining shapes (arrows into top or sides of shapes) as for decisions.
    6. If added manually, extend all swimlane dividers to the same level top and bottom, even if one swimlane is only used for a subset of the end-to-end process.
    Using swimlanes to delineate responsibilities

    Using swimlanes to delineate responsibilities

    As for phases your flowcharting tool may have a function to specify responsibilities and automatically provide the separations around which you can organise your steps.
    If you’re doing it manually, ensure the vertical seperators are subdued enough to not confuse/distract from the boxes and arrows that form your essential content.

Quote of the week (25 May)

This is one of my favourites, not only because it came from our namesake, Isambard Kingdom Brunel (who you should really read more about).

Isambard was commenting in reaction to a move to establish regulations for bridge design (a field in which he was the leading innovator):

“In other words embarrass and shackle the progress of improvements of tomorrow by recording and registering as law the prejudices and errors of today.”

Pretty much sums up a lot of current endeavours around copyright, media piracy/usage and anything from the RIAA or MPAA, don’t you think?