What exactly is all the current hype around UX/UI design methodologies and patterns? And is this a good thing for digital?
Now, don’t get me wrong, I love patterns. As a mathematician, everything I do is about identifying and distilling data into or from patterns which we can then react to, solve or predict new data with. However, whilst a pattern might suggest a particular response, even mathematics allows the practitioner to choose their own route towards that destination. just because the stock price of IBM has a direct linear correlation with the population of brown rabbits in Norway does not make this relationship very useful. Probably.
In my mind there’s a lot of confusion out there over what’s really at stake here. Some people are in the camp that pattern libraries are merely to be used as a reference, to allow a common language to develop across the community – which is cool. I can get on board with that – a little like Esperanto, but hopefully … well, better, in execution. On the other hand, one might argue that a common language for all, by its very nature of homogeneity, is restrictive to creativity. Me for instance.
Others take a more radical viewpoint and suggest that the pattern library is in fact the final solution and that for all future cases we should either A. squeeze the case into one of the existing solutions or B. retrofit the solution to fit the previous as well as this new case. This approach is quite worrying and not just a little bit scary, for oh so many many reasons.
Just because a particular pattern works for one design/company/brand/product does not mean it will work for all – we, the customers, are not numbers at the end of the day.. If you think about how much our communication tools and technology have changed in only 20 very short years. To suddenly suggest that we have achieved a state of nirvana to which a single set of design solutions exists and can now be applied is, to say the least, rather short-sighted. And let’s not forget the old saying regarding free lunches and the scarcity of such a feast. Most of the owners of these libraries are usually selling something aside from altruism. I.e. there is a reason they want you to adopt, be it product related or as a marketing strategy.
You may be thinking that I must embrace the gods of chaos, and whilst there may be a sliver of truth to this, I will now offer a case FOR pattern libraries. Yes, I am very much against some 1984-ish Orwellian scenario where all of our interfaces and interactions fuse into the same journey down identical grey corridors. However, I do think there is a case for a localised, positively focused, homogeneous solution within a given brand structure.
We do know from research that customers hate having to constantly relearn game rules. They don’t close, they leave the allotted path, and they go off and do something much more interesting instead.
Imagine playing monopoly and half way through someone took away one of the dice, you had to go around anti-clockwise, hotels became houses and vice-versa. Madness. And yet a common occurrence, figuratively, in terms of web interfaces. Consistency is always king, or queen maybe. It’s the boss.
But there must be no laurel resting. To survive we must evolve, user testing, tech improvement, constantly challenging the static into becoming dynamic is a good thing.
One of the really cool aspects of a UI/UX pattern library is the developmental aspect. A defined pattern means an existing technical solution template exists across multiple channels. It’s already been been tested, so a testing scenario has already been built, perhaps even as an automated script. Think about that for a second – your UI has been tested on multiple browsers, devices, screens and responsive breakpoints – that’s a HUGE time saver for a project. Because your pattern is in the library, we know where all the occurrences are, we can maintain them as needed.
And perhaps most importantly, we have confidence that the solution can be put into play with a clear timeline and by a resource with a defined skill set and experience level.
And finally, do not underestimate the commitment required of a library for you brand. You will need to have a library structure or tool to contain it, check in and out, asset management, user documentation, an ambassador, regular updates, training material
Several design methodologies and pattern libraries have been documented and raved about – some start at the result and work backwards, others start at the beginning. The atomic model attempts to break down all design templates inside a hierarchical structure. Then we have full modelling where we examine all inputs and outputs or model each entity of the system we are looking at from birth to death (ELH) And finally we have UCD, focusing on the ‘who’ rather than the ‘what’, which looks firstly at identifying the people on our system before we use research, data and insight in order to derive journeys with stories that will show us the ‘what’ we really need to design for.
The truth is that they all work and they all fail and at the end of the day success is more about getting a great collaborative team together than it is about following a theoretical model.
You might be thinking all of the above is just so much mixed messaging, it’s bad, it’s good, it’s bad etc. And you’d be right. SO, to summarise:
- Don’t deny creativity – be distinctive for your brand
- Think about what you want to get out of the library and plan it
- Make sure it a taken seriously, it needs real effort and time
- Don’t be a pattern library nazi – chill
- It’s better to have a large structured library than a small generalisation
- UI/UX pattern libraries are good for projects
- Run patterns through UX, Design, Prototype, Development and Test
- Define a user centric methodology (UCD) for the previous point
- At least try to validate with some UX research – I know, I know.
- Go the next step and include this as a part of your global Style and DAM strategy
My personal choice would be to do a combination of UCD with Entity life history modelling (ELH) and creating a responsive component design and technical library, covering several bases as well as ensuring that we have the business cases covered whilst we are designing experientially. What works for an agency will probably not work for a brand. Most importantly though try not to let inspiration be stifled.
I’ve never had the patience for pure pixel pushing, however I do love to doodle. Truth be told, art kind of passed me by. I never had the ability, or the urge, to attack canvas with brush or clay with hands with any realistic expectation of a successful outcome.
But you don’t need to be a Leonardo in order to draw and use diagrams effectively.
You’ve heard the phrase “A picture paints a thousand words”, which may or may not have been first used by Napoleon, well, here we have something I do believe in.
1. Sample distilled hand-drawn concept wireframe
When I develop these I try to use a single slide. I want to bring the concept across in total including key screens, processes, people, products, usability and at the end of the day it should be enough to allow me to specify a budget.
2. Quick and dirty flow of a journey using Visio
I already had the screens which were created for user testing so all that was needed were 6 screenshots, some arrows and a tiny bit of text and this was enough for the developers to ensure the journey was captured for the system.
3. Captured requirements for a DAM
4. A system flow chart with roles/processes
5. A full lifecycle project representation
But, and it’s a big but, I only believe in doing them to the fidelity required by the recipient. Much as I really love the sometimes very cool output of the various software packages out there, like Balsamiq and Omnigraffle, I simply don’t have the spare time in my budget to spend using them to turn, what is essentially a throwaway into, a masterpiece.
I’ll try not to rant, but, after looking at a few UX portfolio’s out there, I have to say that I find the results quite disturbing. The quality of the output is exceedingly high. … Too high?
Usually, when I run workshops or requirements gathering sessions there will always be some form of diagrammatic output, twenty five sheets of flip chart data, sketches and copious multi-coloured notes which need to be collated and refined. This output is cleaned up briefly to make the scribble that is my handwriting more legible and to annotate important sections of interaction.
This act is what I would refer to as the distilling process – it’s where we let our brain make connections and short cuts and you will probably find a load of extra thoughts coming into the game that weren’t there during the act of recording. A small note of warning here and that is to make sure any amends you do have do not slip off the scope lead and creep off into the distance out of sight of the clients and, more importantly, their budget.
So, not an enormous task, requiring days and days of effort, you can probably accomplish this task in a few hours.
The recipient depends on your personal technical knowledge. The last thing you want to happen is for a developer too far down the line to change anything to suddenly inform you that your design is not feasible and will require an extra 3 buckets of cash. This is design led development and it ALWAYS ends in disaster. So make sure your workshop has a break in it to consult technically on feasibility, if you need to.
The next viewer is usually the client, with whom we will walk through the diagrams to ensure we have clarity and consensus. Next, we have a designer, who will take the (now legible) concepts and create an actual design which, in turn, after approval, will get passed to the developer with my annotations on interaction. I am running over this too quickly and you really ought to look at my WAGILE post to see what steps are really required, in my humble opinion.
As I mentioned, the quality of every diagram needs to be aimed directly at the recipient and should be detailed to the level required and no more. If a UX consultant working for me spent several days building overly-complex or pixel perfect diagrams, I am afraid they wouldn’t be any more, working for me that is.
Clients, especially, will not be impressed at being charged several days worth of time in order for a perfectly usable sheet of A3 to be converted into a thing of beauty – or rather they might quite like it as they know for damned sure that their budget isn’t going to even ripple in the direction of more. Maybe I just need clients with deeper pockets?
I was astonished on one job recently to hear a UX Designer (had recently been upgraded from IA) tell me that they didn’t draw and there were no graphical outputs from a mini-workshop so they couldn’t possibly get me the wire frames until they had been properly Visio’d from her notes, which would be about a day. A day that may have been her very last with that client.
In the case of workshops, the drawing aspect is not a solitary endeavour, it is a graphical form of consensus and is beyond value.
And let’s not forget you don’t have to have static diagrams. There are so many options available to animate your information, have some hotspots to provide deeper understanding, or show a flow of screens with click throughs. Really easy to implement and very useful.
How can we help this process? Simple, invest time in your diagrams. If you find something that works, refine it, template it and use it again. For example I have templates in several software packages, like Visio, which are pre-populated with everything I will need to allow me to draw a pitch system overview diagram. I also wrote a piece a while ago about organising your mind and your data, so the next time you have two hours spare get working on those templates and create a logical space for where to find everything.
If you feel your diagrams are flat and need some oomph, talk to a visual designer and ask them their advice. It might even be worthwhile to get them to provide you with a simple style guide for your template.
Finally, you’re meant to be a UX person and what is it that we do? We test, on real people, on the customers and user personas who we want to target. If it’s a complex concept heading towards a non-techie, then test on a non-techie, listen to their feedback and respond to it.
Diagram 5: Project technical overview concept
This is one of my faves and I have used its template so many times to good effect. It tells a story, showing off the system in total, all of the various machines and tools that make it go, what we want the user to experience, how that experience is created with components and sections and other tools and finally how you the client will manage the system. Not only does it present a complete project picture but it is primarily used as a budgeting tool. If I have access to this diagram I can create a realistic budget to complete the project well before we have any detailed requirements. On the other side of the fence, the client has a visual representation for where the huge amount of cash we are asking for will be going.