Conducting a remote empathy mapping workshop

empathy-map

As a small, agile, multi skilled and geographically dispersed team that works on multiple products, building a shared understanding of needs and priorities for our work is key. Furthermore building empathy with our users empowers us to be better designers.

“In the end, design is all about empathy. This is what leads to creativity, inspiration and breakthrough solutions to problems.” – Leon Segal

Part of my role as UX specialist is to ensure that our whole team builds this empathy which we can carry throughout our work. One of the best ways for us to do this is to collaboratively work on UX artifacts such as Empathy maps.

Why empathy maps

Along with many other UXers, I have started to favour empathy maps as an augmented  form of user persona, as they allow you to focus on what users are thinking and feeling. They help to paint a picture of why users make choices and decisions or take certain actions that users themselves may find hard to perceive and articulate.

We’ve found Paul Boag’s adaptation works better for our team – for the reasons he states in his post – than the standard Empathy map template. Completed maps seem to resonate more than standard user personas and are a great reference point that’s easy to dip in and out of when needed. Furthermore they are quick and simple to produce and easy for everyone in the team to collaborate on.

Collaboration is key

Any collaborative ideation or workshop session generally benefits from everyone being in the same room, but due to numerous constraints this a luxury we can’t always afford – and I very much doubt we’re alone here.

It’s all too easy to just involve the 2 or 3 people that are in the same location as yourself to create such artifacts. But they won’t always build a full picture, or the shared understanding that you’re looking for. Worse still, there’s the urge to assume that your team already has a shared understanding and just plough head first into your work.

Its essential that the whole team gets involved bringing their individual understanding, knowledge, skills and expertise. However running a remote workshop with a whole team can be tricky and requires planning, preparation and patience.

Making it work for a dispersed team

  • Where possible use face to face video conferencing
  • Create your map in an online tool such as google drawings that the whole team can access and contribute to – Here’s our template
  • Allow approx. 30 min per map you wish to create, plus 10 min at the start and end to introduce and wash-up the session
  • Make someone the map owner whose role is to make sure (a) Everyone understands each of the notes and are happy with the wording, and (b) any future edits are done at the consensus of the team
  • When adding notes to the map: Write, Explain, Place – It’s important that no one adds anything to the map without explaining it first
  • Adding photo to the map helps you to visualise a real person to build empathy with
  • Use colour to signify when notes support (green) or detract (red) from your products objectives

Hopefully these tips will come in helpful if you need to run a remote empathy map session. And I’d urge you to try. There are actually a few benefits to taking this approach. Your finished maps can be centrally stored, easy to access, edit and print out when needed. But more helpfully by creating them digitally in the workshop there’s no need to type up afterwards!

Responsive web design (RWD)

“Day by day, the number of devices, platforms, and browsers that need to work with your site grows. Responsive web design represents a fundamental shift in how we’ll build websites for the decade to come.”- Jeffrey Veen

What is responsive web design?

RWD is a web design technique aimed at creating sites that provide a consistent user experience across a wide range of devices and screen sizes. Content, navigation and features should be both accessible and usable, with a minimum of scrolling, panning or zooming regardless of device you use to access them. The basic premise is that the content (written text, images and features) of your site becomes like water.

“Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Now water can flow or it can crash. Be water, my friend.” – Bruce Lee

RWD

Responsive web design is also the most efficient technique for making the same code work across multiple screen resolutions.

What does responsive web design mean for Jisc?

  • Small, medium, large… A single site for every screen
  • Start with user needs, and understand their context of use
  • Take a ‘mobile first’ approach to design and content creation
  • Stop designing page layouts and start designing the parts that make up those pages
  • Choose progressive enhancement over graceful degradation
  • Unobtrusive JavaScript
  • Use language that is appropriate for both touch and non-touch devices
  • Be modular, use design patterns


For further reading check out RESPONSIVE WEB DESIGN by Ethan Marcotte

Designing mobile first

mobile-first

Ever heard comments that have gone something like…

“The sort of tasks that users are performing are too complicated for mobile”
“Analytics show our primary audience is desktop”
“Users only want a desktop site”

When desktop use vastly outweighs mobile it seems obvious to prioritise that as the primary medium. And following a strategy that puts mobile design first seems utter madness.

Mobile isn’t an edge case any more.  

It’s well documented that mobile web browsing is rapidly on the rise – in 2014 it overtook desktop browsing – and continues to grow rapidly. The concepts of graceful degradation and progressive enhancement have been discussed at length online and there are advocates of both approaches. On the face of things they seem fairly equal… As long as you can get the information or perform the tasks you want to do on your chosen device, who cares.

When designing for a desktop first you logically use the screen real estate that’s available to you. The problem comes when you try and squeeze (or gracefully degrade) your awesome desktop UI into a smaller viewport. In the most part you’ll end up with either a watered down version of your desktop site or something that is frustratingly unusable on mobile. Either way it will no longer be awesome.

Mobile first is a design strategy, not a primary use case

When i hear comments like the ones mentioned earlier my instinct is to dig deeper.

Why are the tasks too complicated?
Why does your analytics show higher use for desktop?
Why do users say they want desktop only?

Without boiling down the issues it becomes self fulfilling prophecy.

Mobile first is hard

Taking a mobile first approach means you’re met with constraints straight from the word go, smaller screen, fewer resources, more headaches. It forces you to make tough decisions, be brutal with your content, test your assumptions and be completely user focussed.

Not everyone has the skill (or confidence) to take this approach–or facilitate the discussions that it throws up–but the only way you’ll learn is by jumping in and doing it. There will always be cases where mobile first isn’t the right solution, or a feature simply doesn’t work on mobile, but without validating, testing and taking a mobile first approach you’ll never know what you might be missing.

Tips for designing mobile first

Start with needs
Document the user and business need for every page. If you’re finding this difficult then chances are you don’t need the page.

Mobile first is content first
Mobile first is equally a content strategy. The limitations that come with designing mobile first mean you have to be ruthless with your content. Taking this approach means your design will become more content focused, and in turn more user focussed.

Draw your user flows (and prioritise mobile)
Mapping out how the user will flow through your system and identifying the key steps and interactions before you start designing is essential. For some practical tips take a look at A shorthand for designing UI flows.

Understand the context of use
You may be familiar with user stories, but i find job stories a much more powerful tool to help define the context in which a user wants to perform a task. Check out Alan Klement’s 5 Tips For Writing A Job Story for more info.

Split complex tasks into logical steps
Breaking up lengthy tasks (such as applying for a driving test) into steps will make them more manageable on mobile. Always provide context of where you are in the process eg step 2 of 5. And providing an brief overview of each next step (before you get there), will pre-arm the user and help them connect the smaller steps into the flow of the larger task.

Sketch out your ideas
Treat your sketches as experiments, record ideas quickly, make mistakes and find the right solution sooner. Wireframes will help to communicate and create a shared understanding of your ideas. Sketching is a very accessible format and keeping your ideas rough and ready allows the whole team to feel comfortable critiquing and collaborating on them.

How will it scale up, and back down again
Once you’ve got some mobile first concepts in the bag, scale them up to get the ‘bigger picture’. Designing your mobile concept up for larger screens will give you with more freedom–that may help you see new opportunities–which can in turn inform you mobile layout.

If you’re interesting in learning more check out Mobile first by Luke 

Creating a pattern index

UFV Graphic and Digital Design program

Following on from my previous post on taking a framework agnostic approach to documenting UI patterns I wanted to talk about creating a pattern index as a counterpart to a pattern library, or as a useful tool for anyone designing within a large web estate.

The spark

As with many things, an innocuous looking question sparked a train of thoughts and ideas that lead me down this road.

“What should we do in the event we need UI elements not covered by the pattern library?”

Our pattern library is a collection of user interface design patterns that solve common and recurring design problems. Tried and tested solutions that have been developed over time specifically for us, with both our brand and users in mind.

The best approach to developing a pattern library is to build from the ground up alongside a site as it developed, acting as the canonical design and technical specification of itself. However we had a need to create ours retrospectively, so logically started with the utilities (the grid, buttons, forms, icons, typography, navigation) and a few patterns (masthead and footer) that were required to give a distinct and consistent user experience to our web estate. We then have taken an iterative (agile) approach adding new patterns as needs emerge, allowing it to grow organically. All patterns have been ‘refactored’ directly from jisc.ac.uk, improving code quality and design, as well as developing practical guidance on how, why and when to use.

However, has following this approach meant we have missed an opportunity? What about all the patterns queued up ready for ‘refactoring’ when their need arises? And what about the uncommon patterns that may never make it into our library? We always envisaged that as part of our guidance there would be an ‘in use’ section that would give examples of where patterns from our library have been implemented in our web estate. But what about all these other great patterns that are littered through our web estate?

Creating the guidance required to make all the UI patterns in any web estate reusable would be an enormous task, but creating a pattern index that collects examples and references is much more manageable.

A ‘pattern index’ defined

Wikipedia describes an index as:

“… a list of words or phrases (‘headings’) and associated pointers (‘locators’) to where useful material relating to that heading can be found in a document or on a page. In a traditional back-of-the-book index the headings will include names of people, places and events, and concepts selected by a person as being relevant and of interest to a possible reader of the book.”

I describe a pattern index as:

A list of UI patterns and associated examples to where useful material relating to that pattern can be found in a web estate. An index of patterns, interactions, transitions and concepts selected by a person(s) as being relevant and of interest to anyone working with its counterpart pattern library.

A pattern index is intended as a wayfinding tool, a place to find examples and references of where UI challenges have been met–much like ui-patterns.com–within your web estate. It should be as useful to those new to developing in your web estate as those responsible maintaining it. A pattern index should help to ensure consistency by documenting all the instances where patterns are used for quick reference, whether they’re in a library or not.

“You only need to visit any higher education site to see examples of this [inconsistent UX]. Navigation shifts position, form elements are formatted differently and even typography changes. This happens because it is easier to guess how a button might look then find out how it was styled in the past.” – Paul boag on How and why to create a pattern library.

Documenting UI design patterns

House plan

House plan

From the very beginning of the Jisc user experience and design project we knew that we didn’t want our pattern library to be just another framework. Bootstrap is widely used across our business and it’s fantastic for rapid development, but by its very nature it’s completely open to individuals interpretation of how to apply it. What we were creating had to add more value to the business than just another bootstrap.

At the start of this project CX partners undertook an expert review of high profile pattern libraries, style guides and frameworks. They plotted these on a perceptual map, and asked us to do the same for our vision of what we were creating. There was unanimous agreement that during the rollout phase of the project it needed to be more practical and structured, but as it matured and more sites starting using it that it should become more inspirational whilst still retaining its structure.

Position perceptual map

Position perceptual map

Knowing this structure was essential to the library, we identified two key types of documentation required for each pattern: how to use and how to implement. Bootstrap deals with the the how to implement part, but not how to use. If we wanted to create this balance of structure and practicality, whilst adding value to the business we needed to ensure we had not only the hard (technical implementation) guidance about a pattern, but the softer (UX and design rational) guidance.

I recently came across an article on UX Pin called How to Document Your Designs for Easier Reuse. This peaked my interests because the day before I’d picked up on a comment from a 3rd party back-end developer that was using the pattern library as a reference for how to solve a design problem about field labels. They weren’t actually using our CDN or our specific forms patterns, they were just using our library as a reference point for how solve a UI design problem – without asking a designer!

This made me think about what problem we’re actually solving with our pattern guidance. My belief is that it’s not how do I use this specific pattern, it’s how do I solve this UI design problem. Which is where I found the aforementioned article useful. Firstly it validated our logic for calling all the ‘things’ in our library ‘patterns’. They’re patterns because they are recurring solutions to common UI design problems.

“Patterns make websites and apps more learnable for users. Since they’ve already used the pattern on other sites, users can easily learn how to interact with them on yours.”

Secondly it lists the documentation that you will require to make your patterns reusable:

  • Name – The name of the pattern so you can all recognise it and find it within your patterns
  • Description – A short summary of its purpose
  • Context of use – Where and when you’re most likely to find the pattern put to use (a search box would appear on most pages of a content site, for example, perhaps at the top of the page)
  • Where used – This is a list of links to examples of it in action on a live website or app
  • How it works – A description of the actions a user takes and what happens as a result

We already use many of these themes in our how to use this pattern documentation, but I liked the explicit nature of these headings. It shouldn’t matter whether someone is using our library’s HTML, CSS and JS or that of Bootstrap or Foundation. Our documentation should be framework agnostic wherever possible.

There will always be examples where we need explicit guidance for a UI pattern. We have some patterns that signature to Jisc with a specific context of use, but we need to ensure that our documentation is relevant and reusable even when abstracted from the framework that accompanies it. As we add new patterns and continue the development of our library this is the key focus for all our guidance.

Launching the pattern library

Lego blocks organisedToday we launched version one of the pattern library on ux.jisc.ac.uk – a collection of 30 key user interface elements. These should allow developers to quickly bring a consistent and high quality user experience to new and existing Jisc websites.

When to drop the beta tag

Working out when to lose the beta label is tricky. For us the big thing was making sure the patterns were stable. They should work (for makers and users) and meet our own standards (including accessibility). This doesn’t mean everything is perfect – but known issues should be minor. When we release fixes, makers should be able to upgrade to them without anything breaking.

Effort and experience

Getting this far with the pattern library and the site has been a huge undertaking.

Ben’s fantastic work to produce clean and elegant patterns, extending and developing the Jisc look. CX’s efforts in pattern creation, support and advice. The heroic work of our front end developers, Leigh and Tom, to not only build patterns, but to raise the quality of our engineering, and keep us true to our standards. All tied off with the dark arts of Simon and the back end developers who made the site and the library delivery possible (and put up with us getting used to Git).

Meeting the team behind the BBC’s GEL was a great place to start the whole project – but it’s been a huge learning curve for us all. There aren’t many other (public) examples of what we were trying to achieve so a lot of the time we had to make our own way. We’ll try and post what we’ve learnt here, or if you’re interested then drop us a line.

How we’ll develop the library

First we’re going to start working through our known issues, and tidy up those loose ends.

We’re already working with some site owners to help them adopt the pattern library. We will be working with a handful more over the next few months. These transformations are a chance to iron out the kinks, make sure it’s easy to use, and to give live examples for others to see. We will also be creating new patterns as we encounter problems that need them.

Ultimately we expect use of the pattern library to become entirely self-service. We still want to have close contact with developers and service owners, but hopefully as more of a community – sharing experiences, issues, and through this – identifying new patterns or those that need work.

This regular feedback is how we plan to grow the library (and site). We know that to make the most of our investment we’ll need to keep it fresh – provide new patterns outside of the core set, and adapt and respond to new insight, and changing user behaviours and expectations.

Our ambition

Today is a big step towards our ambition of a consistent experience for users of all our sites. Tools to allow makers to create interfaces based on robust user experience and engineering principles. Increasing quality, reducing costs, and allowing us to react more quickly. Pride, passion and pace. Yep. Think this ticks all three.

What’s in a name

hello_sticker

Following on from my previous post I wanted to explain the logic for the change of name on the project formally known as global experience language.  

In CX partners initial assessment of our web estate they recommended that

“Service mode sites should be made to feel consistent with other Jisc services using modules from a flexible global experience language (GEL).”

In my previous post I said;

Search for global experience language on the web and you’ll find the BBC’s GEL. I’m not sure if they coined the term, but their version is certainly the most visible and well developed example – and it’s an example that we can draw many parallels with.

“The BBC have had to tackle a sprawling web estate that has grown in an organic way, that has been developed by geographically separated and structurally segmented teams. The BBC describe their GEL as “the glue that ties all BBC services together” and that is something that we’re very much striving to achieve.”

We had a vision of how we wanted to unify our web estate and the BBC’s GEL was an excellent example to help people realise this–something tangible that we could share early on in the project and say, ‘we’re building something like this’–and our assumption was that we were building our own version of a global experience language.

The problem with words

Terminology amongst our own project team is a problem, scale this up to the whole business and it gets even worse. Early on in the project we used terms like component, module, element, pattern and template to describe the various ‘bits’ that make up our pattern library, but these words have different meanings to different people.

“Excuse my ignorance, but could you give me an example of what a component is” – Service Manager.

The words we use need to be clear and simple, language that technical and non-technical staff can both understand. Global experience language is a perfect example. During user testing we found that some back-end developers thought the word ‘language’ referred to a programming language that they would be expected to implement.

So this got us thinking was the term ‘global experience language’ right, moreover is what we were building actually a Jisc ‘global experience language’?

So what are we building

The term started to feel too ‘throw away’, as though all we wanted was for ‘the GEL’ to be implemented on website X, Y and Z and then they’re done, as though it was some kind of silver bullet.  

As an internal customer service team we’re user experience (UX) evangelists, engaging with other teams across the business we try to influence and educate in the practices of user-centred design. Just because some of us have UX in our job titles doesn’t mean that we are the only ones that have to worry about it, it’s the responsibility of the whole business.

This is where the BBC’s model fell down for us, they already had user experience and design teams embedded across the business that believed and cared about their GEL, we didn’t. We don’t just need our own pattern library or GEL, we need to build a UX culture across the business.

Jisc user experience and design

So what we’re building is the home of user experience at Jisc. A place that we can share patterns, examples, guides and best practice. A place to get practical advice, learn new methodologies and get inspiration. it will be the toolkit for everyone involved in building digital products for Jisc.

Jisc user experience and design (ux.jisc.ac.uk) is the clearest and most concise way we can express that this is the home of user experience at Jisc. However we felt as UX is still not universally understood as a concept that we the word design needs to be explicitly expressed so that our offer is clear to all our users.

What’s next?

With ux.jisc.ac.uk out of beta in early November 2015 our focus is shifting to supporting the implementation rollout – learning, developing and iterating as we go. We’ll be sure to share our progress, so I’ll be back soon with another post.

Web writing: back to basics

web-writing-banner

As one of three web content editors at Jisc, much of my time is spent editing raw content into something clear, helpful and engaging. At least I hope so!

Training our subject specialists

Jisc has a brilliant team of subject specialists who, despite their busy roles, have been working with us to update our quick guides.

The total number of guides on the site is only going to grow, so a few weeks ago we asked the lovely Christine Cawthorne from Crocstar (who has trained content producers at Government Digital Service) to give the subject specialists a brief introduction to the things they should consider when writing for the website.

Why writing for the web is different

If you’re reading this, I’m probably preaching to the converted. But sometimes you have to go back to basics.

It’s well-documented that people read web pages differently from print and are more likely to scan to find what they need, often reading less than 30% of a page. Helping people scan content without interruption is one of the reasons we favour sentence case over title case (we also think it makes everything feel a little less formal…)

Here are a few simple ways you can help transform your content:

  • Put the most important information first
  • Use meaningful headings
  • Write as you would speak: use plain English and cut the jargon
  • Keep sentences short and concise, wherever possible
  • Avoid long paragraphs
  • Use bulleted lists where appropriate

Even Google is a fan. They agree that writing clearly is good for search engine optimisation.

Writing for the web – for everyone

Being able to structure your content and write clearly for the web isn’t just for use in guides or features. It’s a helpful skill for anyone who wants to communicate something: writing a job advert, blogging about an event, even generating interest in that sofa you’re trying to sell on Gumtree!

One of the tools Christine shared was Hemingway Editor: great for cutting the waffle. There’s also some excellent guidance on gov.uk which dives into more detail.

Tweaking the IA

Help us improve the information architecture of jisc.ac.uk:
take our tree test

While running quite a few big projects* we’re also busy keeping the main Jisc website up to scratch.

We’ve been working with internal teams to test and revise the IA of the site, in particular how we group our products and services. We’ve run public tree tests before and found them to be fantastically useful – though they do raise lots of questions. For that reason, this time Nomensa are running facilitated sessions alongside the online test. This way we should get some qualitative insight alongside the numbers.

If you’d like to get involved then do have a go, and help us keep jisc.ac.uk as usable as possible.


* Some other bits that we’re up to:

  • Our shared pattern library and guidance for all Jisc sites
  • Migrating thousands of pieces of content from our array of websites into one place
  • Rebuilding jisc.ac.uk to provide self-serve tools, and deliver single sign-on for Jisc’s services

We will definitely, probably, eventually, get around to blogging in more detail about these. Promise.

Best seat in the house

Kirsty and Vix at mission control - the best seat in the house

Me and Vix at mission control – the best seat in the house!

Last week, myself, Vix and Rich headed to Birmingham for Digifest. Having helped out at last year’s event on the digital dream wall, talking to customers and listening to their issues and needs first hand, my role this year was much more behind the scenes but vital especially for delegates following online.

With what I reckon was the best seat in the house, dubbed ‘mission control’, I kept an eye on the action from the main hall in between uploading presentation slides from each of the sessions as soon as they had taken place. No mean feat but worth it to enable anyone attending the event or joining in online being able to access all the content almost immediately!

It was a busy but fun couple of days with time to soak up the atmosphere, meet colleagues from across the organisation and check out the exciting technologies at the ‘fab lab.’ The amazing, fully immersive Samsung Gear VR headset took me on a rollercoaster ride and diving to the bottom of the ocean which, for a landlocked sea lover, rounded the event off perfectly 🙂