There's no feeling like the anticipation of a freshly-ordered Amazon delivery. The first half of our delivery just arrived but we couldn't hold it in any longer. The team's new reading list over the next month or so:

1. Sketching user experiences. Getting the design right and the right design - Bill Buxton
2. The Simplicity Shift: Innovative Design Tactics in a Corporate World - Scott Jenson
3. Art & Fear. Observations on the Perils (and Rewards) of Artmaking - David Bayles
4. About Face 3: The Essentials of Interaction Design - Alan Cooper
5. The Design of Everyday Things - Don Norman

Recently I had the pleasure of having lunch with the executive team from an NFP organisation we have been working with for nearly five years. The reason for the catch up primarily being to get together informally and talk about the previous twelve months, gauge how well we have been performing and to talk about the business and any big plans for the next year or so. Over the course of the lunch we discussed recently delivered projects and work in progress as well as deeper issues relating to how the organisation can become better at decision making when it comes to investing in digital.

Here are three key take-aways from the discussions and some thoughts on how to address them:

1. Rethink existing processes before digitising them

NFP's who have been around a while, and even newer businesses that grow quickly often start out doing things using non-digital, offline processes. We know from experience that simply taking non-digital processes and replicating them online never works very well. If a process is cumbersome and time consuming in the offline world there is no reason why just simply translating it into a digital process is going to solve the problem. In fact we have seen the reverse where processes can actually becomes more complex and time consuming once technology gets involved.

The challenge here for both the organisation and the agency is to work to gather to re-think the old ways of doing things and design new processes that take advantage of latest digital technologies. A word of caution here - sometimes this work can lead to tough decisions for the business, particularly when it involves staff restructures or changes to ancient workflows. It can be a case of one step back and two steps forward, buts its worth it if you’re client's goal is measurable success.

2. Talk to users about how they want to consume your content

As is the case with most successful NFP’s; passionate and informed people can be found behind everything they do. With organisations that do a lot of research to inform the programs and initiatives they produce, the focus tends to be very much on content - and quite rightly so given the social value of much of the work NFP's do. However, while informative and rich content can often be in an abundance, when it comes to digital content delivery, the biggest issue facing these types or organisations is getting content into a shape that will work in a digital context. All too often we see content that is written and organised for publishing in print get replicated verbatim on web pages. And who wants to read reams of dense text on screen? Not me.

When this situation arises what is needed is some dialogue with users to find out exactly how they would like to access content and in what formats they prefer to consume it. By taking a user centred approach, incorrect assumptions can be avoided and content can be reworked to satisfy real world user needs. The best time to do this is before any plans for the digital project are finalised. This ensures any decisions around information architecture and content are based on real world user needs and not assumptions. Over time, as deeper understanding develops around the needs of an online audience it may then be possible to innovate around the process of developing content for both on and offline publishing, so that further production efficiencies may be achieved.

3. Its ok to say no

If after taking a brief from a valued NFP client you feel that rethinking a set of processes is the better way to go than simply replicating them online, politely tell them so. Its what you are there for. Remind yourself that you have a duty of responsibility to work with your client to ensure they are not wasting their time and money in creating a system that will more of a beast than a beauty - so be bold. It may be tough trying to convince them that there are better alternatives. So don't go in cold. Be prepared. Your client will ultimately thank you and your relationship will be stronger for it

It's easy for us Interaction/Ux designers to forget how focused on the user we actually are. We know that the user should come first however when the person paying us just wants a website, it's hard to make them understand how important it is for the website to keep their customers happy too.

As Ux (User Experience) designers, we live in a world of sketches and wireframes. We understand technology, what it's capable of, how it works and when is the best time to use it. We have the ability to quickly sketch lo-fi screen designs and talk about how these screens would change based on user actions. We may choose to develop a prototype, we may not. Because of old-world development models, it was always a case of "Do as little HTML/CSS and actual design as possible until the site map and content is locked down. Otherwise we design a site whose content/sitemap will change and as a result, we'll have to re-do the design again and again." Hence, the rise of the wireframe. It was supposed to be the best way to show a client how their website will work without having to go through the iterative process of design. But after years of trying to make this work, what the Ux community (and us here at Surface Media) is finding is that a site wireframe may not be speaking the language of the client.

Sometimes, we're so focused on the end-user - our client's clients, that we forget that what we also need to do is communicate our interaction design solutions to the project team. We need to identify user groups within our own team and document our interaction design accordingly.

Communicating with business owners/project owners

Like we do with our client's clients, we should be asking: What is our client's background? Are they marketers? CEOs? Are they from IT, Architecture, Design disciplines? Once we establish this we need to decide how we communicate with them. A simple task-flow model might work well for those from a science/IT background, it's what they're used to seeing and can easily comprehend a user's decision process with boxes and arrows; but to a client with a marketing or design background, it looks like another boring flowchart and subsequent interest levels plummet to 0%. Conversely, a ux design comic used to communicate a user problem might get a laugh out of IT and be blown-off as just a silly story, but for someone in HR or a small business owner, it might just have them 100% thoroughly engaged and willing to participate in a user journey session to flesh the characters story and uncover hidden end-user needs.

Communicating with designers

Designers hate being told how to lay things out. It's what they are paid to do. If it's not their job to decide what colours, typography and visual heirarchy to use, the role of visual designer is degraded to a simple pixel-pusher. Not only is it a boring existence but it can hurt team morale. A high-fidelity digital wireframe/prototype then, with boxes laid out in a clickable interface ready for them to 'skin' is not the tool to communicate your interaction design with designers. We've been trialling a method in the studio where page functions are identified and priortised in a bullet list format. Give this to a designer and what you receive is something completely unexpected, but it still solves your problem and often, better than you could have articulated in a high-fidelity wireframe anyway.

Communicating with developers

Developers often don't have a designer's eye for how it looks. If it works, the job is done. Give a developer a series of photoshopped, high-fidelity designs and you won't get back the same thing without multiple meetings and frustrating iterations. However, arm a developer with a functional list; "User need to be able to do x" along with a set of photoshop files describing the user action, followed by the resulting system action (and some very low-fi prototypes for certain, more complex functions) and you're on your way to a 1st time functional product, and a happy developer.

It's pretty clear, after being exposed to the world of Ux design for so long now, that there's no one 'best approach' to communicating your interaction design to client and/or project team. However, by accepting this and working with it, it frees you up to take a more agile and less process-driven approach to your Ux documentation. Some clients like to read about website features as a 'functional list', others prefer to call them 'user stories' and respond better to them when they're related to a persona. For every client that understands a 'paper-protoype', there's another that can't understand why we're working on paper when we're building a digital artefact.

The lesson learned so far? There are no easy shortcuts to documenting interactions. Not only do clients and teams vary from project to project but so too do budgets and technology used. The trick is to stop trying to fit a square peg in to a round hole but to learn about the shape of the hole first, the background of the team, the language used by each client/organisation, and then wittle at your peg so it's a perfect fit everytime.

Have you ever been in the following situation?

One of the best ways to get the most value out of your digital agency is to ensure they are being briefed in early on in the project life cycle. 

Metro trains have a lot more than faulty brakes and scheduling debacles to deal with on their quest to become a more user friendly service. For commuters, just getting out of the station can be challenging.

(download)

Click here to download:

Commuters_divided_on_Metro_tra.zip (1.96 MB)