What the heck ever happened to the 90’s?

9 04 2008

I remember being a senior designer for a company (who shall remain unamed) with a friend of mine James Peek (sparkos.com) doing all sorts of design work but mainly for online sites.

Back then, 100kb was considered big for a site, and even deal breaking if you were the Government.

Nowadays, I’m willing to bet no one hardly ever thinks about the size of the page, well at least that’s the impression I get anyway.

Look at this!:

Apple.com (on 9/4/2008) – 576Kb

ebay.com.au (on 9/4/2008) – 596Kb

Microsoft.com (on 9/4/2008) – 264Kb

Adobe.com (on 9/4/2008) – 716Kb

Amazon.com at a scale tipping (9/4/2008) – 1MB

See now the way I see it, it’s almost broadband bloat. It’s almost a given to many designers that broadband will be in place for the end user, so we have no issues about making half megabyte sized web pages or worse (tutt tutt Amazon.com).

I recall the day when a friend of mine was gloating about how he developed a space invaders clone within 1, yes ONE kilobyte!

Now maybe I’m being a bit of a fuddy duddy, but surely SURELY 1Mb front pages are a bit irresponsible and just plain lazy. Back in the day, I along side my fellow pixel pushers, used to go to great pains to ensure the graphics were web optimised, so they would be light, and load quickly, thus not annoying the wholly bejoinkers out of the end users.

Heck we even got so tricky as to use background colours in our …. *grimmace* table cells to save pixels downloaded.

I think James even managed to do a client side web page editor in flash with under 150Kb at some point, AND it had font controls even!!!!

Of course this all raises the next question, with the advent of mobile browsing, and all that it entails (dodgy wireless broadband radio cards and so on) are we heading back to the 90’s? do the now current interface designers need to take some lessons from us old hands, and start to think about getting our websites on a bit of a pixel diet?

I think so…. I think so indeed.

ps, well done James for your site still being trim taught and terrific at a miserly 84Kb.


Design Authority – Part one

21 10 2007

At my presentation this year at Web Directions South I spoke briefly about the role of the Design Authority.

I’ll start this off by saying that there is in my mind, not one role that is defined by Design Authority.

There are in fact three.

The differentiating factor being the context and therefore your viewpoint.

Programme Design Authority:

This Design Authority is single point of truth for the design of a Programmes outcome configuration. Programmes deliver benefits to an organisation or entity. The projects that are children to the Programme, are responsible for delivering the capability that will deliver the benefits that are sought after by the Programme.

In the program me context, the Design Authority marshals what capabilities are required to deliver the benefits, and subsequently the outcomes from the sub-projects.

Over time, through feedback from the sub projects the Design Authority will monitor the development and the alignment of those projects with the parent capability requirements (or Capability Profile)

Enterprise Design Authority:

Similar to a Programme Design Authority, however the Enterprise Design Authority, holds a persistent or lasting role. Programmes have endings, much like projects (duh because of their implicit relationship). The Enterprise Design Authority preserves the Enterprise business intent, and provides design assurance for the programmes of work within the enterprise.

Visual Design Authority:

This is the role that is more common around the traps and would be familiar to anyone working in a development house.

The Visual Design Authority is the role that is responsible for the design strategy, as it relates to all things visual or interactive. This includes aspects like how the visual appearance evolves of a website, or what methodologies are in place for the design of interactivity or business processes, whether or not information architecture principles are applied and how and when and by whom.

Everyone needs to set up their Design Authority in the way that best suits the purpose. The term design means different things to different people, hence since I come from more than one place (being both the interface design, enterprise design space) I can see both points of view.

Why I like the concepts around the Design Authority is that it disambiguates where the assurance responsibility lies. In many contexts this role can be very useful, especially in terms of assuring alignment of effort outputs with the original vision, and in terms of providing consistency and stability in terms of visual design output and approach.

Even for small business this can be useful, because where resources are limited and time is short, wasted effort that isn’t true to the original goal can be expensive and sometimes crippling.

Within the private web development field I would even actually say that the concepts behind a Design Authority, could hold a lot of value (from a visual design authority view) in terms of a Quality Assurance Regime. Where the outputs of a development team can be independantly reviewed against the original or captured client intent, which ALWAYS looks good.

I’ll endeavor to post again about the role of the configuration manager, who enables the requirements of the Design Authority through managing the configuration of the programmes efforts.

This Design Authority role is ever expanding particularly as there is more and more rapid work or agile work being done in the software / web development space. In light of that, if you would like to pitch a question about what a Design Authority role could do for you, or if you want to comment on how you use a Design Authority already, I’d love to hear from you.

Capability profiling – quickly – cheaply – for small sites.

3 10 2007

Good evening everyone!

Diving straight in, Capability profiles.

These are a fantastic little doodad which are very very useful for figuring out what a project has to deliver.

Often I’ve found myself starting off a project, and jumping straight into outcomes as derived from a vision statement.Something like this:

Vision: “We want a better online presence to improve the front end of our business.”

Outcomes: “well, lets build you information pages, and build in a blog, with an events calendar….” and so on.

But there is a critical step in there that often gets missed.

And it’s fiendishly easy to do, and very very valuable.

A capability profile is a set of statements, which can describe in plain English, almost conversational terms, what capability is needed once the project is done.


Well, my learned friends a capability profile would look something like this for a fictitious company.

Capability profile

For: That Company over yonder.com.

1. Ability to be able to offer time limited sale opportunities to our clients.

2. Ability to be able to offer special online services to a member group.

3. Ability to manage that membership group, and send out email offers and other sales or marketing materials.

4. Ability to maintain the content and page structure ourselves.

5. Ability to have a photo gallery of our products.

6. to have purchase oriented transactions be performed through the site.

And so on….What this gives you as the developer / designer / whatever, is a really useful communications tool to use with your client to help them define exactly what the site is going to do.


But absolves both / all parties of needing to look carefully into what is going to be built exactly.

In Agile managed projects (and waterfall ones for that matter), the capability profile can be used as a single point of truth, owned by the Design Authority role (see my slide share on Natural Project Management With Notes or Without Notes)

Now, clarity around what the end state capability should be is really useful in a financial sense as well, becuase particularly with Agile developments, having clarity of vision can really save the development team a lot of money and time.

I should note as an ending statement, the capability profile is NOT a static document, and should be reviewed by both the project team and the owners at every iteration.

Particularly in an agile development, because as we all know, because agile is so powerful new desires for more capability come up ALL the time.

To support anyone who is interested, I have a neat little set of .PPT / .KEY worksheets and a workshop agenda process which are great to use to help work through the development of your capability and outcomes profile.

If you’d like to get your hands on it, drop me a line!

Childrens toys leading UI design?

28 01 2007

I often look at the toys my two boys get for inspiration and insight into UI design.Now this may seem like a stupid thing to do, kids toys are for kids and I handle design for complex business systems.So what’s the gig?Well I actually intend writing several articles about this and what I’m finding.The product I assembled or disassembled more correctly was an “imaginext” castle from Fisher Price toys.Now, when I pulled the thing out of its box, I in typical fashion ignored the instructions relying of course on my amazing talents and sharp mind to be able to effectively assemble a childs play thing.Typically also, this gamble never pays off and I’m left sitting on the floor hunched over some instructions I can barely make out because I’ve half assembled something in the wrong order and am likely looking at something that more accurately resembles a ball of twine over the Batman’s lair i originally purchased.Anyway, as I was undoing the last of the 14 million wire ties holding the toy castle in its cardboard cocoon I noticed that at the top of the toy there was a little toy king held in place with a white surround around his feet.The other knights were contained in a little plastic bubble “see but not touch” wrapping of the open type display box it was all contained in.The king stood at the top of the castle above the drawbridge (see pic).imaginext castleNow here’s the UI bit. The surround holding the king in was coloured white. There were no other parts on the castle that were white….other than the white plastic reinforcements that were fastening the aforementioned wires which restrained the toy in it’s packaging. I’d been happily removing all the white plastic bits from the toy and it wasn’t until it came to remove this last piece from the toy, that I realised this.Fisher-Price in all their wisdom had decided to colour code all the removable parts white!And I, even with a well trained eye completely automatically keyed into the “obvious” visual clues that led me to instinctively know that all white bits should be removed.(Reading the instructions later revealled that they had indeed done this on purpose, and that I had done the right thing.)So there you have it. As kids we are taught games which teach us how to spot differences, and make choices based on those differences. “Odd one out” games if you will.By purely instinctivly playing the “odd one out” game with this toy through the practice of removing the packaging, I was going to achieve my goal!Can this same thinking be applied to more complex interface design? Probably. I’ve not invested much in the way of figuring out and active application for the “odd one out” game in terms of application or web interface design. BUT!!! Surely there are many other games we played as children which we can tap into in terms of our designs to enable our users to intuitively interact with our software?Kids toys… well I never.Next article will be about another toy I quite like, which is the Leapster game from a company called Leapfrog. It’s excellent, and my 3 year old son can use the device like a pro. In his world, instructions are meaningless. Poor little tike is still working on numbers and how to eat custard while resisting the temptation to stick it in his brothers hair for a larf.Users first. Particularly if they are kids.

Loony tunes

16 11 2006

To tune or not to tune. That is the question.

Actually, that was the question! I was in a meeting the other day, with a collection of developers.

And amongst other things, which I’ll write about later, I got asked this:

“So in your opinion Ben, is there a significant value in tuning screens to show / hide capability from a user when designing an interface?”

Hiding my dumbstruck look, I answered “a very resounding yes my friend!”.

Now here’s what I thought was funny, and not really funny Ha Ha either.

To this particular guy, who I might add is an expert technology developer, the thought of having some functionality hidden from the user because they have no need to ever really use it, was just appalling!

Of course after a short thinking moment on my behalf, I remembered something which I had noted long ago about the expert technical worker profile.


When I did some initial research into the UI requirements of expert technology workers, I came across this sentiment:

“I’m a computer expert, therefore I want to have access to everything, so give me everything, and I’ll decide what I want to use.”

That led me down a line of further investigations.

I found that quite repeatedly, expert computer users have little problems cognitively filtering large navigation models.

They typically can remember hundreds of functions and associate them easily with their appropriate names.

This was quite contrasted from the Process Worker profile, where more menu options fed confusion about what they were supposed to do. To them, the concept of having more advanced and less commonly used functionality hidden away was perfectly fine. One person even likened it to keeping my less used pens in my desk drawer and only keeping my favorites out on my desk top. A sort of ‘workspace tidiness’ concept came across to me from that comment.

I’ll draw against the Microsoft Windows ‘Start’ menu. If you examine the menu containing the installed programs, there generally is more than 20 odd items in there. More if you have a typical development setup.

I’ll now ask you to compare that to the Apple navigational systems. Look at the way apples hide away the majority of the lesser used items, and bring to the forefront more commonly used ones. It allows you to customise it to remove even more, or draw out even more.

To me, apples are well suited to the average people. Normal people.

PC’s tend to lend themselves to more advanced users.

And if you look at the marketing campaigns for Apple, this simplicity of use is one of their primary selling points. In fact in one commercial I saw them handing the crown for processing capability and ‘number crunching’ to the PC world.

I guess the overall points here are these:
– Tuning interfaces has significant value, as long as you are tuning on researched or validated UI requirements and profiles.
– As designers you should be aware that some technical experts may not understand why you chose to use a tuned UI.
– Because of this, your role needs to include helping your developers understand that they don’t need to understand why you designed the UI a particular way, but that you came to the design to meet the users requirements. In many ways, they are doing the same thing by meeting the technology needs of the user. Your job is to make the technology usable to the users.

Know your users. Don’t think you know. Actually KNOW.

tough tablets

18 10 2006

I mentioned earlier that I would discuss why I have a preference for using tablet PC’s.

One of my key theologies is to maintain speed and ability to meet demand through streamlining processes, and refining what I / my team members do.

Speed designing discusses this, but not exhaustively.

Why the need for speed? What happened to quality?

All good questions. I’l answer them more fully later too. But for now:

Speed. I am speed.

Tablet PC for me was a revolution for my line of work. It enabled the practitioner to have all the bonuses of working with paper prototypes, but the following features:

  • removal of the source control problem (coffee coloured delete key)
  • ability to change design very very quickly without grappling for new paper sheets
  • version control
  • ability to use projectors and work more easily with larger groups
  • ability to combine handwritten notes with site photos, screen snapshots, graphics, anything!
  • ability to copy and paste the basic frames without needing to redraw your screens, big bonuses if you use the tablet for your initial screen layouts

Yeah, great ben. What activities do you do that make the tablet PC so useful?

Paper prototypes.

I’ve always been a big fan of working from paper to start then translating that to electronic form as part of the refinement.

Now, traditionally i would walk around with great slabs of A3 in my hands, with a collection of coloured pens and textas in my pocket.

With the tablet PC, I just take the tablet and its stylus. That’s all. everything I need is in the tablet.

Collaborative work
When working with groups I use the tablet PC over the projector so I can make reference to business requirements documents, reference websites, user profile information, existing applications and so on. On top of that I can use the tablet PC to take snapshots on the fly of favorite sites / materials / whatever, and start scribbling on them and adapting them in front of the group to get the ideas flowing.

Because the tablet PC does not lend itself to really fine or precise work, it forces me to be forgiving of myself to accept that and move quickly.

I remember many times years ago, I used to DREAD having clients work with me over a design at my desk. Because they would nit pic about little things, and I would be slow because photoshop had to render the pics or the HTML would have a heart attack about something I slapped in there.

With the tablet PC, I don’t have those problems. I can work quickly with a group of clients, catching thoughts, flicking past things, scribbling and so on. it’s GREAT.

Site Visits
Ahhhh, the old site visit. They are great aren’t they. Kelly goto refers to them as “deep hanging out”.

I take photos, ask questions, draw schematics of the physical site, make notes about workstations, capture voice notes from the people I’m visiting, all that stuff.

Because of the ability to combine all these features in one device (barring the photos of course, but the tablet has USB2 or card readers typically) I can obtain so much more data quickly and reliably. So I don’t need to rely on recollection post visit to complete my notes. Au contraire! my notes are done as soon as I leave the site and get in my car.

Because the format is electronic, I can use them as finals. I’ve gone through the whole saga of writing up site visit notes in MS word (yay!). This is much better, I take my ‘one note’ files, publish them to MTHML and voila! instant notes. Electronic, and versionable. Editable post event too if need be! Emailable even if you wish!!!

Are these things a silver bullet?

Nope. long way off. I’m typing this blog using a macbookpro, which has no handwriting input capabilty at all.

Why? it frees up my brain to deal better with this work. Plus inputting large text into the tablet pc (using the stylus of course) is just a painful exercise. Keyboard is the only way to fly here.

Also any type of fine / detail work is utterly beyond the device. Photoshops a joke, code work more so.

Browsing is great, as is reading word docs. Editing them, powerpoints and ergh… excel is simply too ridiculous to explain here.

My desktop has several machines on it. A desktop PC for most of the work, a tablet pc for all the tasks described above, and a Macbookpro for my more creative efforts.

My last comment

If you’re in this line of work and you do a lot of user centred design work particularly those described above, having a Tablet PC will certainly save you time. Lots of it.

Saved time buys you credibiilty and instantly gets you more capabiltiy and responsiveness of your service. Also and this is a crucial note:

The tablet used correctly will enable you to draw up intiials, hand them to developers instantly, and they can use them to build immediately. (presuming of course the project is agile (iterative) and the developers can work in abscence of actual look and feel, which is becoming more common these days).

This functionality alone will save a project days of time (not effort, duration, there is a corresponding effort of course, durations the key one.) That saved time, translates to money and delivery response. You need that in order to be successful in a large environment.


You will need to lear to use it quickly. It can take a bit, particularly if your handwriting is as appauling as mine.

You will need more machines also, just having the tablet will kill you for the rest of your work.

Bens pics?
Fujitsu stylistic slates with separate dock, and peripherals. Best of breed, and perfectly suited to our work. Plus they are super light, perfect for site visits while being OH&S sound.

Toshiba M400. small, clamshell design. Light still, carries more portability as a properish workstation if you travel a lot. Packs core duo power, YEE HAAA.

Users first yall.

The lows and highs of fidelity

17 10 2006

I’ve spoken before in ‘speed designing‘ about low fidelity.

This is nothing new to many of you, but for some of you that are still working through the skill this post might help to clear up what the hell I’m talking about.

My designers are encouraged to work on a methodology that is iterative, building upon an initial baseline and through consultation and feedback refine and build upon the baseline to develop a finalised design specification.


A baseline is essentially the rough foundation design that very loosly describes or illustrates the design.

Low fidelity
When a designer works with the clients on the development of the baseline, this is where ‘Low Fidelity’ screens get used.

Low fidelity screens are generally hand drawn, have notes written all over them to describe behaviour and iteractivity, and generally cover most of the variants of screens in the application or site.

They are low fidelity because they are drawn rapidly, disposed of easily and very very very cheap to make. A large portion of time can and probably should be spent doing the low fidelity screens. Sometimes as much as 60% of your overall design time.

This is because the designer will design the core interactive behaviours of pretty much all of the devices to be used in the later versions.

Level 2 Low fidelity
Level 2 low fidelity or medium fidelity designs are the next step up from that. These ones also generally do not have any real style applied, but they do almost work, are sometimes written in html that is quasi functional, and can be used for user centric testing purposes.

Level 2’s are generally only of specialised screens or process flows that are highly complicated and would benefit from deeper usability testing.

Don’t waste too much time on these making them look nice either, black and white is fine. With big boxes that say “logo goes here” will work just fine.

High Fidelity
This is what many designers jump straight into. Now I appreciate why, it feels nicer, the outputs are nicer, everything looks good. We can get bound up in the technicalities of fibonacci calculations and colour palette matching, advanced geometric mathematics for relative size matching, painting with our fingers an so on.

The catch with it, is that it can take around 4 hours to come up with such a screen, particularly if you’re talking a home page, or primary core design theme complete with navigation model.

The High fidelity screens are used for the look and feel tuning, the actual visuals. These screens will most accurately reflect what the finished product would look like.

It’s not often necessary to actualy model any of the actual screens specified in the previous two levels. Generally, the high fidelity screens will contain various bits and pieces which can be used to form the final specification for how things will render on screen.

Building iteratvely
Above I wrote about building upon a baseline. Perhaps this will help:

Of a 40 page transactional service:
low fidelity screens:

  • 60% of the overall work time
  • 90% of the overall screens
  • 100% ugliest

level 2 low fidelity screens:

  • 20% of the overall time
  • Only the necessary screens to be used for testing or whatever purpose you decide is needed

High fidelity screens:

  • 20% of the overall time
  • only the screens required to illustrate all the required elements of the look and feel.
  • 100% fully rendered in either HTML or static images.

The key part with what’s above, is that you are building upon what you did in the previous level(s). But through building upon what you did before, you also get more selective with what you develop. The idea is that as each level requires more time to deliver, so in order to keep delivery times under control do less screens!