Also in response to your site visits, you have worked with business representatives and subject matter experts to draft a number of context scenarios, which effectively illustrate the intersection of future business processes and the future system.
Lets assume that business requirements have been developed in tandem with or before this point so it is fair to say that you and your client is starting to get a pretty good idea of:
- What motivates “the business”
- What motivates your users, and
- How the system might meet the needs of both at a very high level (high level as in; we’re not talking about buttons and drop-downs yet)
Next step is to start to determine what functions might be devised to deliver to point 3 above. This may take the form of functional requirements and if you’re lucky, the business analysts (BAs) are preparing use cases in order to draw these out. Your working closely with the BAs so you have road tested the use cases with your scenarios and - after patching holes in either or both – they line up pretty well.
You start designing screens…
The BAs think it is a little early, so does the business (“but the functional requirements aren’t even finished, how do you know what the screens will look like?!”) but they ease into it once they realise that you know what you are doing and they actually see the system (or at least wireframes thereof) assembling itself before their very eyes.
Everything is going (s)well. You have even designed some novel visualisations of data that will help users get an overview of key information, summarised at a glance – something they have never been able to do before!
The BAs think it is a little early, so does the business (“but the functional requirements aren’t even finished, how do you know what the screens will look like?!”) but they ease into it once they realise that you know what you are doing and they actually see the system (or at least wireframes thereof) assembling itself before their very eyes.
Everything is going (s)well. You have even designed some novel visualisations of data that will help users get an overview of key information, summarised at a glance – something they have never been able to do before!
…but then, one of your particularly detail–oriented business reps regales the assembled workshop with the one-in-a-million story of the client’s client who -back in 1993 - had three different genders at once and 2,500 case notes on file (when the average is 120 case notes), and who was legally deceased while most of this happened! “Consequently”, he proclaims, “your summary at a glance view won’t always work and should be canned”.
One of the technical BAs mentions a very different but similarly exotic example and before you know it your inspired solution is dying under the weight of a small handful of “corner cases”.
To summarise; you are about to sacrifice functionality that will benefit the overwhelming majority of users almost all the time because there are some very rare examples where it doesn’t work quite as well.
One of the technical BAs mentions a very different but similarly exotic example and before you know it your inspired solution is dying under the weight of a small handful of “corner cases”.
To summarise; you are about to sacrifice functionality that will benefit the overwhelming majority of users almost all the time because there are some very rare examples where it doesn’t work quite as well.
This situation arises for me all the time, literally daily (on some level).
To a certain extent, this kind of reality checking is essential. For example, I spend a lot of time running real data through my mock-ups so that I can see if the design holds up to real world volumes and data types. However, when taken to the extreme, this kind of activity becomes a kind of corner case bounty hunt that pays out in personal (not yours) ego points rather than anything of value for the project, let alone users.
So I have a new approach…
Design for 95% of cases and cater for the remaining 5%.
This means that we spend our time and effort (and requirements budget) making things work really nicely for the large majority of people most of the time and as long as it doesn’t totally stuff things up for the remaining very small minority, we’re good.
So, using the example above, if in the rare case of the multi-gendered, really busy, dead client, the summary screen extends below the scroll break in the web app rather than being summarised up on one screen, I don’t give a damn!
It happened once in 1993 – lets move on. I did a few things in the mid nineties that I’d rather forget too, lets do it together people. Kum Ba Yah.
Print one of these babies out, pop it up on your design wall and gesture at it nonchalantly whenever somebody threatens your project with death by corner case.
Since I raised this issue in workshops a few months back and started asking “How often does that happen?”, things have changed on my project. In a very ironic Pavlovian twist, one of the more vociferous corner-case-assassins recently asked the workshop if we weren’t getting bogged down designing for cases that rarely – if ever - happen. Amazing.
12 comments:
Good morning !!!!... (hello) I read with great interest this post! are an Italian boy who by chance comes to your blog.
But his excellent work in this moment that the world feels twenty very weak, it will be very sought after!
A virtual greeting
Carlo
Thanks for your kind words Carlo.
Matt.
Great post Matt. I think developers are quite prone to falling into this trap too - it's a good reality check.
You say this problem arises 'daily' -- but I put it to you that there are some days when this particular situation does not arise and furthermore I suggest that there are some occasions when this inconvenience arises greater than one time and hence I feel that the situation cannot be accurately described as daily because at certain times it occurs with either less than or greater than a daily frequency, and that furthermore a failure to consider these corner cases undermines your entire sentence which should be retracted forthwith.
Oh, wait.
lb
Good read. Corner cases most often rear their ugly head because they're just so intriguing and bring out the detective in us all ("Very interesting. These clues MUST be telling us something... just not sure what it is.").
Similar to how good use case writers often include exception cases, I normally acknowledge corner cases ("Interesting. Let's note that.") but quickly move on. The owner/originator of the issue feels heard and validated, and the issue can still happily remain as part of the design process.
If you've applied the right design techniques, these corner cases eventually get pushed to the side... and hopefully fall off. If they manage to cling to the side and ultimately work their way back into the picture, then they're worth reconsidering ("maybe we should open this path to expert users").
Great points Joel. Modern western thinking relies on conscious rational analysis - I think this makes it a lot easier for people to identify problems that to identify creative solutions. I think we also have a tendency to fear ambiguity and to want to shut it down rather than exploring further into the darkness in hope of finding an answer (there is a fine line here of course).
I agree completely that corner cases need to be acknowledged - this is often all the proponent is seeking.
The other point (that an app architect raised with me in response to this post) is that almost as many projects have troubles because corner cases aren't explored fully and this is a good point too. Importantly, my suggestion is that corner case be observed and catered for but they don't drive the solution (particularly the UI) at the same level. To use an analogy, you wouldn't install automatic double sliding doors at the cleaners entrance to a building. It is about focus.
Good read.
Couple of things where it lacked emphasis.
Firstly, this type of design methodology is good in principle, but more often is misused by 'poor designers'. If something does not work properly, it is that 'other 5 percent'. Hence, all cases should be analysed in completeness initially to determine the break and should not be used as shelter for bad work. Other 5% should not be taken lightly.
Secondly, emphasis is given to usage. It is important but not everything. If 95% of users generate 5% of revenue, and 5% generate the other 95%, there may be another thinking of design (or is this a corner case!). Hence other attributes like cost, development effort, data management, etc should be looked into along with percentage of use.
Then there's the designer who relishes in the corner cases and sees them as a 'challenge' to their elite design skills, hides themselves away for days and comes back with what they see as an elegant solution that impresses all their colleagues, but bewhilders users, while wasting time that could be spent on the 95% stuff.
Great post Matt.
Matt, highly unimpressed. There's a lot of hay in this post, not very appealing.
Hey there Anon,
Sorry you were so underwhelmed. Care to contribute to the discussion with specific recommendations on what you felt was missing?
Always keen to make my posts more usable.
All the best.
Matt.
I will give this article to a few people I know who always criticise everything, interface, design, style, colours, layout, navigation, content... the truth is you cannot tailor a good looking fits all suit. In attempt to do that you will produce a mere average which won't be fit to compete. Since we live in the 'market of one' era I believe the appropriate solution would be to cater for everyone. How? I heard someone talk about remodelling the interface based on the user data we have, and the starting point is the referrer string. For example if someone looked for "blue widgets" then your website should rewrite itself to feature that element (product, service, story, media) to cater for that...a nd then learn from every next step the user makes. And now from science fiction to reality. What Matt suggest is the best possible solution in this time of relatively limiting technology.
Amiable dispatch and this fill someone in on helped me alot in my college assignement. Gratefulness you for your information.
Post a Comment