So what is all the current hype in UX around UI design methodologies and patterns and is this a good thing for digital?
Don’t get me wrong, I love patterns. As a mathematician, everything I do is about identifying and distilling data into workable 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 the solution and this is how innovation is achieved.
It’s also true that patterns can be misleading; just because the stock price of IBM has a direct linear correlation with breeding rabbit pairs in Norway does not make it useful. In UX/UI terms I am suggesting that what works for one design/company/product does not mean it will work for all. Think about how much our communication tools and technology have changed in only 10 very short years, to suddenly suggest that we have achieved a status quo to which set solutions and designs can be applied is, to say the least, short-sighted.
Patterns are good when they are real. 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 following a theoretical model. My personal choice would be to do a combination of User Centred Design (UCD) with Enity 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 like 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 hope 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.