Design + Banter 18

See ya later, suckers

Rik Lomas (@riklomas)
Founder, Steer & SuperHi

  • Moving to NYC. How do you move there and be self-employed?
  • Google says it’s a nightmare.
  • Rik got a lawyer, went to see here.
  • She asked, “What is your job?”
  • He rambled, she asked, “What is a developer?”
  • They went over and over it and came up with a single sentence: “I teach people to make websites.”

User wants complicated thing –> simplify –> User can do that thing
(Applies to both the lawyer and to building websitess)

5 problems that SuperHi solves

Learning to code is scary

  1. Have sensible defaults
    • Get simple stylesheet when you open SuperHi
  2. Remebering difficult concepts
    • Colour: small color next to hexcode that brings up colour picker
    • Make margins and paddings easier: again a hover state that shows the margin and padding
  3. Technical copywriting
    • Making Git easier to use for normal users
    • Two buttons: Save to history, go back in time
    • Try to keep copy as simple as possible
  4. Getting a site online
    • “All you need is an FTP program, and hosting platform, and a domain…”
    • Make it easy to get a site online: create an account, create a project, publish.
    • Most tools are aimed at advance users. For beginners, be opinionated.
  5. If a tool isn’t there, make it
    • Example: making background videos easy

Our job is to help people do the things they want to do, and not get in their way.

Use your words: talking about your work

Camilla Grey (@camillagrey)

  • Was head of content at Wolff Olins. Brand strategist before that.
  • Does both brand & content.
  • Likes to help designers write.

Make friends and win work and get promotes and influence people

There is a need for articulating the thinking behind a design.

Things she keeps hearing:
* “We keep losing work to F***** ****”
* “We need to editorialise our process.”
* “We want to be a part of a community of digital leaders.”

  • Make friends: – Assumption that a blog post needs to go viral. The most important thing is connecting with your peers.
  • Get promoted: – Every agency: the designers that get promoted fastest are the best at communicating why their idea is the best.
  • Win work – The ability to talk about your work in the frame of a brief you’ve been given.
  • Influence people – Talk and find other ways to communicate your visuals means you can help shape the future of thinking in your field.

Five things to help you get going

  1. Practice – you don’t have to publish the first thing you write
  2. Read – identify who writes well, and unpack why their writing works for you
  3. Plan – get someone to “emotionally spot” you. tell your boss you want to do more writing. get them to read it and give you feedback
  4. Respond – if you can’t think about something to write, write about something happening in the world around you
  5. Move the last bit to the top – The place where you land at the end of it all is where you should probably start.

The Anti-Complacancy Design agency

Neil Cummings (@NeilCummingsEsq)
Creative Director, Wolff Olins

Big D

  • Design is getting a seat at the table.
  • No longer a part of R&D, product, etc.
  • Bigger customers, bigger challenges, bigger questions design needs to answer
  • Big companies are bringing design in house
  • Young talent want to work for big brands as much as big agencies
  • The type of agencies that are being brough in house are agencies taht have a specialist function (mobile, service design, ux, innovation agencies)
  • A big agency shouldn’t be seen as a specific function. Wolff Olins is disassociateing themselves from “brand.”
  • Wolff Olins needs to be seen as an “and” business
  • Briefs come from big and fundamental business challenges, WO needs to be able to attack those and draw on a broad range of skills.
  • Spirit – Wolff Olin’s spirit is “push it” – designers should be open to push every aspect of what WO does
  • Push ambition – use this to drive your work forward
  • Push people – this is about getting the user into the conversation during the development process
    • testing is often about validating pre-formed ideas
    • how do you involve users to make design more radical, more thoughtful?
    • example: sent a box with a button around the world, and asked people: “This is what a box that is going to do one thing for you. What is it?”
  • Listen – this opens up how you can make your brand come to live. It comes to life with the tiny interactions people have with your business.
  • Lessons from Tim Allen
    • about participants not audience
    • experience design is about people, and those people aren’t you
    • experience design is about making (brining in and integrating a development team)
  • Push craft – this isn’t just about typographic craft, finding new ways to find visual effects that you want, how to make your ideas more relevant, make your vision replicable by others,
  • Push culture – when you create ideas for business, it’s hard for them to replicate it. They are kind of anti-design. You have to teach them how to design. Give them the tools and create spaces where it’s comfortable to be creative.
  • Push process – you have to be serious about how you design the process of your project. Better ways to design things aren’t in the brief.

JAM 2015

Note: These notes were taken live, so there will be gaps, grammatical errors and other mistakes.

10 Lesson I Learnt the Hard Way

Pip Jamieson (@Pip_Jamieson)
Founder, The Dots (@The_Dots_UK)

“I’ve seriously fucked up along the way.”

1. Hire happy positive people

  • Team is the most important thing in building a product.
  • People who look good on paper might not be right for your business.
  • “I want people to come to me with solutions not problems.”

2. Don’t be afrtaid to work with people offshore

  • Competing with Google, Facebook and other big companies for talent.
  • Development team based in Sri Lanka. They’re amazing. Zero attrition.
  • Product & design are in-house, but dev is offshore.
  • Tools: Slack, Jira, invision

3. Keeping a team

  • “I’ve lost staff because I’ve burnt them out”
  • The chart is great: performance, arousal, Panic Zone
  • You can push a team too hard
  • Team can’t work on the weekend
  • They have to leave at 7:00
  • Constantly getting the trained up

4. Building a product driven culture – meet users

  • When they actually showed the interface to creatives, they hated the look and feel
  • Surveys: typeforms
  • What I find with surveys is that people recommend changes to twhat they see. Chatting with users results in finding out what people’s challenges actually are.
  • People go to word mouth when hiring. Talent is important, but cultural fit is more important.
  • We would never have known that if we hadn’t just listened.

5. Building a product driven culture – hn

  • Team is so passionate that the idea flow is so overwhelming
  • We can’t build everything
  • Internal pitch days every two months
  • If people have come up with a great idea they put them in a folder. Every two months they choose their best two ideas. Pitch for two minutes. Team discusses it for two minutes.

6. Prioritising ideas

  • Priority matrix

7. Down and dirty testing

  • Lots of ideas, but some are shit
  • We get people in every week to see how they are using features.
  • Tools: hotjar for heatmaps, tableau for data collection (pulls in data from analytics, back end, accounting software)

8. Design rules!

  • People expect beautiful things now. They expect usability.
  • invision: prototype and show to users

9. Product development – 5 whys of mistakes

  • Try to get to the core of what the problem is
  • Site went down for two days. Root cause: not robust enough testing or robust enough go-live process.

10. Celebrating the wins

  • Glory wall (not a great name)
  • Feedback from users, great places we’ve found, good talking point for when investors come in

Designing a Better Onboarding Process

James Gill (@JameJGill)
CEO, GoSquared

1. What onbaording entails

  • The management of the early stages of a relationship between a business and a customer. (Collins dictionary)
  • Onboarding is hard.
  • (missed his definition)

2. Ways to improve

  • Think about the staes of our app: Awesome screen, but also Empty and Error states.
  • Onboarding is a flow.
  • Sign-up —> Homepage —> Empty —> Full-on awesome
  • Examples: Developers vs. Marketers
  • Onboarding needs to not piss off either of these users
  • Reduce the # of steps
  • Get to Wow ASAP – focus on the important stuff
    • Every step in the obarding process is a hurdle
  • Set sensible defaults – It’s easy to push decisions off to the user, but it’s lazy product management.
  • Gamify – Think about how to get people to do things, though not necessarily in their first session
    • You don’t need to offer a reward, just having checklist is enough
  • Emails are part of onboarding
    • Make the relevant
    • Don’t send too many
    • Deliver happiness – don’t just spam people
  • Notification (Slack stops sending emails and automatically sends push notifications.
  • Set up a weekly task to sign up as a new user
  • Measure onboarding
    • Good metrics are actionable
  • Define successful onboarding (Install traffic code and sees traffic spike)
  • Chort analysis

3. 3 examples

  • Sunrise – two steps (both because of Google) and you’re there
  • Apple Watch – push the onbarding into an app, most beautiful QR code
  • Slack – only ask for an email address to sign up, then get you to fill in your profile by using Slack


  • Marvel – prototyping
  • Sheperd
  • Olark – live chat
  • Drip – very nice onboarding emails

Good sites

  • – see “The next feature fallacy”

Where Do Good Product Roadmaps Come From

Will Swannell (@wswannell)
Founder & CEO, Hire Space

  • A product roadmap shows how a product is likely to develop.
  • It aligns stakeholders and allows effective planning.

How to present your roadmpap

Five things that a good roadmap has:
* Transparent and accessible
* Can have regular attention brought to it
* People can leave easy feedback and engage with it
* It should be limited in size
* Can be quite easily editable, torn down – set the expectation that this is where we are likely to go

What should go on a roadmap?

  1. Is it big?
    • Is it something that everyone really, really needs to know about?
  2. Is it going to shift a KPI in the next 4 months?
  3. Is it scalable?

How items get (and move) on a roadmap

  • Stakeholders – Team, users/customers
  • Time – Get stakeholder and devloper to give it a number in the fibonacci sequence to estimate this
  • Data, e.g. dropoffs in different funnels across different cohorts
  • Dependencies
  • Decision maker – voting, but groupthink can make bad product decisions, each product should have a single owner

And end-to-end example

  • Venue Groups, e.g. Oval Space has a sister venue: Pickle Factory
  • You can wind up with two users who are managing related spaces.
  • #1 customer service ticket – “What’s my account?”

Product’s Perception And The Needs of Its Customers

Karolis Kosas (@karoliskosas)
Creative Director, YPlan (@YPlan)

  • Too many things to do in London, but people don’t plan.
  • Couldn’t cater to everyone with three events, which is what the original app had.

  • Adding more events meant it wasn’t reliable, so the decision was made to add structure (move from a corner store approach to a Sainsbury’s approach). What was needed was something in-between these two.

  • Intent – predict the intent of people going out.

  • Context
  • Resulted in Categories: Date night, going out with friends, Sunday Brunch, Stay Dry, Free culture

  • People like the quirky and niche things they find on Yplan because they can show off to friends.

  • But the data showed that mainstream was the bulk of the tickets sold.
  • Added a website to pull people in to the big stuff.

  • A lot of customers say that don’t plan a week in advance.

  • Not true for bigger events, they book to get the best deal and are flexible with the dates.

  • For events like theatre, it’s not about the cheapest price, it’s about the value for money (e.g front row vs. sat behind a pillar).

  • Reliable supply – the more supply you have the better the conversion is going to be.

Design at SwiftKey

Scott Weiss
VP Design, SwiftKey

Three components to design at SwfitKey

  • UX Design
  • Visual Design
  • UX Research
    (Skipping copywriting, motion design that they do as well)

Functional roles

  • 1 VP Design
  • 2 Senior UX Designers
  • 1 UX Designer
  • 2 Associate UX Designers
  • 2 Visual Designers
  • 2 UX Researchers

Daily Scrum

  • What did you do yesterday?
  • What are you going to do today?
  • Do you need any help?
    People used to go into gory detail about what they did, but these questions can avoid that.

Co-seating with Engineers & PMs

  • Design sits together, but there are hot desks amonghts the engineers and the product managers

Design Kanban

  • Swim Lanes
    • Typing Experience
    • Visual Design
    • Strings
    • Research
  • Status
    • To Do
    • In progress
    • Resolved
    • Closed

Design Wiki

Weekly Sprint Demos

  • This is when the engineering team shows what they’re working on
  • If people aren’t pulling their weight, it shows. So does doing extra.
  • Demo wall gives everyone the opportunity to know what’s going on

Visual Style Guide

  • Borrowed Google’s style Guide
  • Built their own style Guide
  • Documents patterns, but not every bit of design

Brand book

  • Brand isn’t logo
  • Tone of Voice
  • Typography
  • Colours
  • Graphic devices
  • Collateral

Building Culture

Tim Davey
Co-Founder & Head of Product, OneFineStay

Defining your culture

  • Very nebulous thing?
  • More than ping pong tables in your office
  • “the way a collective of people make individual decisions”

  • Types of culture

    • Product-driven (Apple) – Make what customers want you to build
    • Customer-driven (Amazon) – Make what your customers want
    • Engineering-driven (Google) – Sell what you can build
    • Sales-driven (Microsoft) – Build what you can sell

Communicate the vision

  • They made 6 motivational posters for their cultural values. These didn’t really work.
  • Instead, they distilled it into values:
  • Heroism. Go out and be with the customer if they’re having a problem. You end up taking people who hate your product and you turn them around.
  • Craft (data-driven development) – Focus on taking people who are interested in your business and making them more interested in the business. This makes sense for later stage businesses.

Embed it with process

  • use process, to enforce cultural habits that overcome decision fatigue
  • Confirmation bias (issue for customer-driven cultures) – A tendency to seek evidence that agrees with our position. Looking for data to support your hypothesis. You should also be testing an anti-hypothesis when A/B testing.
  • Authority bias (issue for product-driven cultures) – Tendency to over-value the opinion of those who are seen as an authority on the subject. OneFineStay does Crazy Eights: get people who are working on the problem to do eight different versions, no matter how crazy they are.
  • Bandwagon bias (issue for sales-driven cultures) – Tendency to do things because many people do the same. If you have to do something because CEO makes you do it, test it.
  • Overconfidence bias (issue for engineering-driven cultures) – Tendency to belive ourselves less likely than others to experience negative life events. “I can do it better than anyone else.” Use prototyping to test ideas.

Building culture

  • Who’s driving?
  • What is your focus, right now?
  • What processes do you need?
  • DO IT!

Putting People At The Heart Of Government

Anna Wojnarowska (@voina)
User Researcher, Government Digital Service

Within GDS

  • Digital (
    • Digital by defaults
  • Technology (Anna sits here)
  • Data
  • Operations

What’s the need?

  • Gov’t IT spending is 1-2% of GDP.
  • 4 million desktop computers in UK gov’t.
  • Some teams mark slow hot-desking computers with black dots.
  • GDS wanted to show that procuring computers for people could be done differently.
  • Technology at least as good as people have at home.

Our approach

  • GDS says that user needs are more important than government needs.
  • Civil servants are users, too.
  • Anna was told to find out what it meant to be a civil servant
  • She has a digital anthropology background, so she wanted to go do ethnography for a year, but couldn’t.
    • Agile – need to go test things with people and report back.
    • User research as a team sport – every member of the team needs to understand users in the same way. She couldn’t go along. Other people came with her when she was doing interviews with users.
  • GDS approach
    • Build empathy – understand who the people are that you are delivering to. Cabinet office seen as young people who would welcome change. GDS actually seen as a threat. Used personas to understand people. Personas were completely detached from roles.
    • Break artificial divisions – People saw technology needs in terms of roles. Instead, GDS focused on what people need based on their context. 7 different profiles (probably too many).
    • Make the information useful. – e.g. Found out what percentage of the population each of the 7 profiles were. Useful for those who needed to supply devices to these people.


  • Mobility or flexiblity?
  • Look holistically – Think more broadly than just introducing change into one organisation.
  • Tailor innovation – Don’t just introduce a new device because it’s new, but because it is better for you. Also ensure that people know how to use the device.
  • Develop skills – Instead of investing in new technology, think about what new technology will do to users. What are the skills gaps, and how can they be addressed? Development is something that civil servants struggle with. They often leave the government because of this.
  • “It’s more than a device” – Change does not have to be limited to technology. Change in process can address the core of the issue.

My journey to Data-driven product

Graham Paterson (@GPat_UK)
Product Manager, Intuit

Data is more than just traffic and conversion

  • How TransferWise does product: It’s not the leadership team that decides what to do. Every product manager decides what they want to work on.
  • No one is ever wrong, they just have access to different information.

What is data-driven product design

Three key aspects:
* Delight (e.g. NPS, return rates, social media sentiment)
* Impact (What improvement have you had to your customer’s lives?)
* What to do next

Focusing relentlessly on your users

  • When I was building products, I was doing it for myself.
  • Divorce yourself from the process and focus on the metrics. Are they improving for your users?

Two types of data

  1. Company-based data
  2. Focus on customers (focus on customers)
    • Important to store this in one place, so you can build up a picture of your users.

Segment as much as is relevant

Example: NPS score started going down. Panic. Looking at the data revealed that score stayed the same in UK, but was lower in areas where the company was growing.


  1. Solve for one person
  2. Solve for their segment
  3. Solve for more segments

Data for roadmap ideas

  • User feedback
  • NPS surveys
  • Your sales team – they have greater customer empathy than anyone else in the company
  • Customer contacts

Customers will tell you…

  • People will offer suggestions about how to improve your product.

Good data means testing quickly

  • You can quickly test improvements

Research For The Rest

Rachel Ilan Simpson (@rilan)
UX Designer, Google Chrome Team

Creating the surface between a person and the piece of code that does something for them.

Sense of resistance to doing user research in startups and large companies.

“User research” sounds daunting.
* How does it tell you something that a survey won’t?

Talking to users is scary.
* Gets scarier the further along you are in the development process.

User testing allows you to course-correct sooner rather than later.

Let’s know what to make and how to make it.

Each step of the way
1. Identifying user needs
2. Meet those needs
3. Iterate the idea
4. Are people using your product?

User research is more than a report – It shouldn’t just inform your product, it should change it.

User research should be the backbone of the product. Best way to do that is to bring in the whole team.

To do this, you need to tell stories.

User research is about empathy. It’s in light of this empathy that a team will understand why they need to make changes.


  • Intercept interview – short interviews done in a public space with a wide range of people.
  • In-home interviews – longer interviews done in the home.
  • Card sorts – set of cards with themes to be sorted into categoreis.
  • Usability tests – putting a user in front of your website and seeing what they do.

Trip to India

  • Communicated insights in terms of stories of real users.
  • Connecting user needs to the product.
  • Created prototypes based on insights & tested with remote user testing.

A less daunting method – pulse testing

  • Run a usability test with a small group of users every two weeks.
  • Rocket Surgery Made easy has a similar process. Four hours every month, including a lunchtime debrief.

What users are thinking when they use your product (according to Seth Godin)

  1. What is it? (Very important.)
  2. Do I trust it? (Judgement made in the first few seconds of using your product. Ask them: what does this remind you of?)
  3. What is it offering me? (Clear proposal of what that is.)
  4. How do I get it? (Call to action.)

Research isn’t something you do.

It’s something you practice.

Evangalize your insights

Use pictures, stories and videos as much as possible.

Make real change

Every user testing session is an opportunity to change something about your product.
Start with low-hanging fruit and go from there.

Standards.Next – Cognition and accessibility

These were notes taken live, so they will contain errors, omissions and ridiculous typos.

Antonia Hyde

Accessibility beyond code

Video of Martin – ebay

  • Video (YouTube): Martin using eBay
  • Video (Easier YouTube): Martin using eBay
  • Types “ebay” into Google
  • Clicks first link – eBay
  • types into eBay’s search box. ** Searching for CDs and Picture frames ** Showing the mobile phone page (on ebay? he said, this is website that sells mobile phones) ** Enlarge (to look at mobile phones) is useful. ** Bought phone for £2.99 – didn’t work. ** Making a bid.
  • Looking for how to buy mobile phone ** Click “buy now” rolling over and over, but doesn’t work. ** Got there in the end.
  • He was good at computers, knew the site.
  • Site had big meaningful pictures.
  • Search was consistent
  • Layout was clean
  • Enlarge icon & text worked – they reinforce one another
  • “Buy it now” problem – appears twice once as text and once as an image. You would think they were both actions based on where they were placed.
  • “Buy it now” tells you that it is available to buy, but you can’t click it

Video of Martin – amazon

  • Video (YouTube): Martin using Amazon for the first time
  • Video (Easy YouTube): Martin using Amazon for the first time
  • “nice and bright”
  • looking at sizing – brings up another window
  • orange border is helpful
  • getting frustrated
  • Using account – “How would you go into my account?” ** Found it. ** Can’t see because of pale grey on account screen
  • Sign out
  • Not enough big, meaningful icons. (except for product pictures, shopping cart)
  • Bad typography
  • Poor contrast
  • Buttons are not defined enough
  • He did not have access to areas of the site

Screenshot of site in progress

  • Big Pictures
  • Confusing words linked (green) and defined

Another comment ###’Making everything literal will annoy other uses.”

Escalator picture (tube)- picture * Consider the image looks like you should run down the escalator * Not literal enough

  • Group things together.
  • “i” icon (for information) didn’t work. Questions marks for both Help and What is this site about.

Audience question – just watching w/o asking questions during user testing? * She feels it is important to facilitate learning by asking questions.

Icons plus words: less room for error. *Q: Standards or best practices for icons? * Yes, but I missed it.

Color coding can be elegant * Guardian * very helpful

Allow people to change text size and color schemes * People don’t know how to change their browser settings * Also means you don’t have to damage your design.

Space around things can give the impression that things are bigger. * BBC Home Page – weather pictures not large, but in their own container emphasizes them. * Audience feedback: far to busy for me. Who was this?’it’s not my responsibility” * Everyone shares responsibility for making a site accessible – developers, content producers and managers.

  • Content is useless if people can’t access it. Don’t lock them out. People tend to blame themselves not the website.
  • Videos will be on youtube.
  • Blog:
  • Twitter @hiantonia
  • YouTube:

Jamie Knight

Autism, the Internet & Antelopes

Austism isn’t * being stupid * being difficult

Autism is * a different thinking process * a spectrum

Sensory process

  • A lot of information coming in at once, processing can be hard
  • Example: can’t read when there is noise in the background
  • Try to get away from

Language Processing

  • Videos w/ people talking quickly
  • “Turning words into ‘almost sign’”
  • Rewatching videos over & over to try & understand


Little social things * e.g. “Go and wash your hands in the toilet” * e.g. “Adding friends” means different things on different social network sites, on facebook means two different things

The web is empowering

  • Web has been his career
  • In retail couldn’t keep up with what people consider normal

Paying Council tax

  • Didn’t go very well
  • Asked for numbers but didn’t tell you where to find them, unless you get them wrong.
  • “Print for you records” – paper on printers are “records”


  • Henny: Follow up on video. How can we make it easier to understand?
  • Jamie: Captioning. Transcripts. Making sure you communicate context.
  • Henny: Using a screen reader. You built your own?
  • Jamie: AppleScript and VoiceOver. Microformats & embedded semantics. Wrote a script to look at the html and restructure the page and read it in the “correct order.” Ignore intro.
  • Bruce: could we use to show the usefulnese (to Microsoft, et. al.) the usefulness of HTML5 tags.
  • Jim: And ARIA role=”content”
  • Marking something up well doesn’t always mean it’s accessible.
  • Please don’t use “title tags” (e.g. attributes) He hears it 3 times!
  • Snow Leopard. Trackpad has a one-to-one relationship between the trackpad and the screen. Very easy to use.
  • Screen readers that try to sound human & Screen readers that try to sound clear. Some aren’t phonically accurate. Prefers dialogue & things written in a “human voice” to sound human. Sounds stupid for a robot to say “I” or “me.”
  • Get an sticker
  • Finds high level thinking more challenging
  • Explaining translating language to sign. Learned to sign & talk almost at the same time. When he reads something, it turns into “smoky signals,” then turns into something he can understand
  • Couldn’t spell equilibrium (letters too similar), but could spell it in sign (letters are distinct).

David Owens

Lessons Learned Doing Usability testing


  • Trouble using complex instructions
  • Had to rewrite user testing scripts. Provide context. Make them more explicit.
  • Looking

Lesson #1

  • Make sure your testing script doesn’t make things more complex than they need to be.

Lesson #2

  • Placing context first (skip links)
  • Move cursor through the site in the order you’d expect them to be from looking at the site. People with autism will get confused if they are looking at the site and using a screen reader.

Lesson #3

  • Using Widgets on websites to control the way pages are presented.
  • Richard (learning disabilities) couldn’t remember how to change text.

Lesson #4

  • Hit flash. Just gave up (had tried to make accessible controls.) Put controls first.
  • Understand preconceptions and work with them.

Sharing Results of User Testing

Share results of testing. Share lessons learned. A centralized website for sharing results?

Another Lesson

Don’t stop one person taking advantage of something because somebody else can’t.


Q: How did you keep records? A: Used Shore Trust. Spent day at testing centre in Wales. Having client there helped. Client was involved closely the whole time. Makes it easier if the client sees someone having a problem.

Audience coment: build text resizer to work with browser resizing, then build html widget on top of that.

Ian Pouncey

Content and Cognition

Ian works at Yahoo on the front page.

Will Cover #How to use content #Forms #Things to avoid


  • Navigation – keep consistent across all pages
  • Fonts – don’t use too many
  • Interactive elements, links and buttons – Leave css alone. Makes buttons consistent across all sites


  • Headings – clear & meaningful. represent content
  • lists – fantastic, focus concentration
  • Whitespace – it is structure. Want a separation between headings and paragraphs.
  • Clear differentiation between content types. Make form labels, etc. distinct from regular content


  • users are task-driven. don’t want distractions


  • contrasting blocks of color. Don’t make navigation bright pink. It’s just distracting
  • Don’t use auto-playing sounds.
  • Moving content – ads that
  • Pop-ups – this includes lightbox


  • Adequate text size and line hieght (10px as a minimum, but 11px or 12px )
  • Line height should be 1/2 the size of the text itself.
  • Limited line length. Users with difficulty reading often have trouble reading long lines (80 characters). Avoid “rivers of white” – don’t justify text. These can “suck focus into them.”
  • Colour contrast
  • Short paragraphs. Each paragraph focused on a single point.


  • Users will use
  • Text-resizing
  • Support user styles
  • Page zoom vs. font-resize – each user will determine what they prefer. There is a problem with people knowing they can do these things.
  • Don’t set widths in ems. Can’t do text resizing without page zoom. Give the user the choice.
  • Work without images or styles. Your site may never be used this way, but your content may be.
  • Provide an API of feed.


  • spelling and grammar can be a major blocker for people who have trouble with reading. Get screen reader to read back what you’ve just written. Avoids spelling
  • Definitions of terms – abbreviations acronyms technical terms
  • One subject
  • Summarize – introductory paragraph is useful

Audience comment: Printability

Let’s make something example

  • avoid positional language (e.g. “top right”), assumes styles and an understanding of what “right” means

Generated content

  • Content inserted with CSS
  • Not read out by screen-reader software
  • Use on in cases where the content is presentation
  • Use image to show where the search box is (image w/ arrow pointing to the search box)


  • Do they cause confusion? Needs more research.

Audio and Video

  • Can often help
  • Keep it simple
  • Speak clearly
  • Don’t have a beard which makes people not able to read your lips.

Tasks (for preventing spam)

  • 2 + 2 vs. 2 / 2 (if you don’t know what “+” or “/” means, these can be confused and have very different results)
  • Don’t assume simple tasks are easy
  • Same applies to “what colour is the sky?” – language problems
  • Blog:
  • Twitter: @IanPouncey

London Web Standards May: Structuring CSS

It’s that time of the month again. London Web Standards will be meeting on Monday, 11 May.

This time, Justin Cormack of Squiz UK will be leading a discussion on Structuring CSS.

He’ll be covering techniques for creating modular, maintainable CSS. Along the way, he’ll be talking about Squiz’s mashable design, Nicole Sullivan’s Object Oriented CSS and dynamic CSS generation techniques, such as SASS.

It sounds like it’s going to be a fantastic presentation and should lead to the usual lively discussion.

If you’d like to join us, please RSVP on the meetup site.

London IA mini conference

  • Location: Guardian Offices, 90 York Way, London, W1W 6DS
  • Tag: #iamini

These were notes taken live, so they will contain errors, omissions and ridiculous typos.


  • Speaker: Ken Beatson


Take away one thing that you can change in your work

# 5 minutes of something from your every day work.


  • 5 talks
  • 1 workshop
  • More participation. Shorter, more interactive sessions.

Introducing Information Architecture at The Guardian

  • Speaker: Martin Belam (The Guardian)
  • Presentation: Introducing Information Architecture at The Guardian
  • Guardian just won Newspaper website of the year
  • Joined Feb this year
  • First IA @ the Guardian
  • Process (was): Product Manger -> Designer -> Software Engineers (Agile, 2 weekly sprints)
  • Product Managers: IA = wireframes
  • Designers: IA = Visual Hierarchy
  • Software Engineers: IA = Domain Driven Design (CMS)
  • Embed UCD in product development
  • “Ambush User Testing”. Take Silverback out and ask people how they get their news!

URLs should be: # Permanent # Addressable # Discoverable # Open

  • Using tags for content aggregation pages – who tags?
  • Keyword manager! – official job title ** Keywords added by jourrnalists, editors, etc. ** Manages items & keywords moving from one section to another
  • Open Platform – asking people to use their their content rather than erecting paywalls
  • Building – most environmentally friendly building in London (Kings Place)
  • “Producing a newspaper is an information service, and the Internet is an information platform.”
  • “Weave The Guardian into the internet.”

Ten minutes on Agile user experience

  • Speaker: Cennydd Bowles (Clearleft)
  • Most agile is bad – rushing headlong into coding w/o understanding the problem space.
  • Devs tend not to understand the big picture
  • “User scented design” – results of agile dev, related to genius design * Agile Manifesto – set of values, no process mandated
  • Model Users in Iteration 0 ** Personas ** Concept maps ** Goals ** Use cases
  • prioritise user stories – designers must be involved ** find out about user stories ** flow from personals and scenarios
  • Jeff Patton – workahead – research ** Research n+2 ** Design n+1 ** support n ** Test n-1
  • Get the structure in place – let devs set up db, get data structure right
  • Design the obvious stuff first – profile / product pages
  • Involve the users in every iteration
  • Needs senior people
  • Good communication – designers can’t be separate from developers* Article: Getting Real About Agile Design


  • Horizon factor – push components into a subsequent iteration
  • Agile is light on documentation – gives time to think?
  • Buying time with the backend – how do you avoid backend constraints? ** Takes time to set up the environment? ** Talk to the devs, DBAs etc. Ask what they’re working on
  • Avoid problems by sitting with developers while they’re making it.

Why users don’t follow instructions

  • Speaker: Phillip Winwood (Usability Tester)
  • Psychology background

Scope of the talk

  • Get out of central London
  • Think in terms of people who don’t understand what is going on
  • Software in general (not just web)


  • People’s brains are pattern matching systems, works with tricks – apply known patterns to new things
  • What people know affects how they interact
  • William James: Infants perception involves a “buzzing, blooming confusion”
  • Don Norman & affordances – ‘pull me’ doors that need to be pushed
  • People have learned that you put the website address in Google b/c it works ** That’s the model they have in their head
  • users don’t like to read ** of the Active User] – academic paper (see ** in psychology ** production bias – people want to get things done, ignore dealt ** assimilation bias – use what you know to solve a problem
  • users aren’t a blank slate ** applying what you already know makes it worse ** see Don’t Make Me Think – people don’t want to think, want to apply what they’ve previously done to the current situation
  • learn until you can make it work, then you stop learning ** asymptote of mediocrity
  • Word Manual (Word 2 – 1991) – 800 pages! ** User’s don’t read manuals – never got used.
  • Recall vs Recognition ** Hearing your name at a party. Your brain changes focus ** More difficult to recall than recognize
  • Bottom Line: knowledge is always partial


  • Q: What happens when people don’t have preconceived notions about how a phone / camera will work? ** A: Pitch terminology at the right level. People don’t have enough time. Time is the killer.
  • Q: Is there anything you can do to encourage people to read some instructions? ** A: Open up the potential of the product: “READ ME FIRST” manuals – a piece of paper that floats out with vitally important information
  • Q: Quick guide is useful, but pitch it as benefits for the user. ** A:


Good talk, despite the technical difficulties.


  • users are busy, distracted
  • users are different, they all have different experiences
  • very few are or will ever become experts

Spec docs from Axure wires

  • Speaker: Ken Beatson
  • Slides and a software demo all in one. Exciting
  • IA, Design in UK; devs in Belarus
  • requirements are important
  • wireframes are used, very few prototypes
  • muppets how dancing cheese sketch?
  • iterative deployment of modules

Axure demo

  • he uses two fields – display rules & what’s changed since last version
  • walk stakeholders through jpgs of wireframes
  • you can export a word document from Axure ** often good enough to send to devs ** sometimes he needs to generate prototypes


  • Q: In Axure, once you start to add other features, do the spec documents become less useful? ** A: Yes. If you generate a prototype, the spec docs is less useful.
  • Q: (followup) What are other people using for creating heavy documentation (Axure vs. OmniGraffle). ** A: Stop-motion animation output to vimeo. ** A: Mallof has some good blog post ** A: Getting more sketchy. Interactive Prototypes are the documentation.
  • Q: How to capture change. ** A: Capturing rationale is more important.
  • Q: What do you get your clients to sign off? ** A: Talk to your clients and pick reasonable clients.

Great discussion on “locking clients down” vs negotiation. No real resolution, though.

Design Consequences workshop

  • Speaker: Leisa Reichelt
  • Presentation: Design Consequences: A fun workshop technique for brainstorming & consensus building
  • Solution to the problems we were just talking about
  • Used to write beautiful documents w/ annotations ** people didn’t read them or didn’t have the skills ** we can’t ask people to be literate in wireframe reading
  • Get people around the table
  • “Pull problems to the front of the process.”
  • She uses this a lot during the project initiation phase

Design your own hat exercise (“Design Consequences”)

  • Sketching exercise stops preciousness surrounding design. Nice! I like it.
  • First person sketches a solution
  • Hand off to next person, who picks a part of the sketch and carries it on to the next level. What happens next?
  • Really useful and fun. Generated some useful ideas.

Leisa continues:

  • Two things that happen: *# People realize that they have a picture in their head, and that there are different solutions. *# Good to involved front-end developers who often have ingenious solutions.
  • including people early on improves communication with them
  • afterwards: *# Design one version together (cheap option) *# extract concepts onto sticky notes and affinity sort/rank (KJ Method)
  • recommendations ** do a pilot session ** make sure the design question is clear ** do a design warmup exercise (e.g. something to entertain a dog, irritate an enemy) – get people sketching ** invite a multidisciplinary team (including the people you most fear) ** be creative with materials / stimiulus ** always show example output (show that your sketches are sketchy! show your worst work!) ** bring energy (jelly beans! “spike their energy with sugar.”)


  • Q: Would you consider spending longer on wireframing. ** A: Different exercise. This is getting ideas out there. Getting it perfect would be a different project.
  • Q: Do you use this to teach people a lesson. ** A: Use it to show the work that designers do and take the mystery out of it.
  • Q: Do you have clients who think you’re getting them to do the work they are paying you to do? ** A: Even though I have designer in my title, I find myself facilitating design among my team.

Interacting with forms

  • Speaker: Matthew Solle
  • Big problems with forms.
  • 3 categories *# Non-critical: signing up for email *# Non-critical but critical to fill in: Online share dealing account *# Critical: Tax, passports, visa, etc.
  • non-critical forms that are excellent ** Huffduffer ** Google account (see if your account name is taken) ** Google search ** delicious – very clear ** radar – is that the electronic business card site? ** Audience comment: recall vs. recognition?
  • non-critical but problematic ** Amazon – log-in ** Google account vs. Gmail account – two different places, very confusing ** Halifax – application form
  • Passport / ID card is coming (critical) ** “Secure data” ** Do online forms communicate with this? ** Will this be done badly?

(More) Audience Feedback

  • Verified by Visa – critical, but crap?
  • – you need to be approved and they text you. Jane Austin did the IA.
  • Jonas Löwgren – Ethical design
  • Interesting: TFL has poor wayfinding to prevent bottlenecks elsewhere in the station.

Interactivity – how IAs learned to stop worrying and love designers

  • Speaker: Tom Coombs (www.manwomanandchild.comlink)
  • Flash –
  • dull wireframes result in dull websites?
  • Silverlight demo – “Contoso Fixter” – Silverlight deep zoom – you can zoom in forever and just download what you need
  • Flash demo – timeline & tweens – (me: it’s been a long time since I’ve seen flash. brings back memories.)
  • “Dynamic specification” ** Really easy to design for interaction ** Demonstrate interactions ** Easy to build interactive prototypes
  • Really cool – webcam hacked to see infrared light to create a multi-touch interface.
  • Video: vimeo “Playing with Multi-touch” by IDEO labs link?
  • A new kind of interaction. Not actually happening on the web. Exciting to play with that stuff.
  • 3D – Flash demo of 3d-like behavior.

Audience Questions

  • Q/A: Flex for prototyping? A lot of the interactivity is build in?
  • Q: Where are you going with the touch table thing? ** A: Thinking about it at my desk. NOt sure where it will end up.
  • Q: Tutorial for infrared stuff? ** A: A lot of people working on it. LIbraries, code bases, etc. link?
  • Q: Resolution of Prototypes? What are user testing responses like? ** A: The Flash mockups are conceptual, but can be too high resolution for some situations.

London Web Standards April

This month’s London Web Standards meetup is fast approaching.

We’ll meet on Tuesday the 14th and discuss Joshua Porter’s Designing for the Social Web.

I’ve started reading the book over the long Easter weekend, and I’m impressed. I’ll be posting a full review after the meetup. I’m halfway through the book, and it already feels like another Don’t Make Me Think: one of those books that I want to give to anyone that has anything to do with a website. It’s about more than just design, and his advice applies to every website. After all, like it or not, we’re all a part of the social web now. We always were.

If you’d like to join us, please RSVP on the meetup page.

I’ll see you there.

WordCamp UK 2009 update

WordCamp UK 2009
I’ve been fairly busy (and preoccupied) over the last couple of months, so I haven’t had a lot of time for blogging or for helping out with the preparations for WordCamp UK 2009 (in Cardiff on 18-19 July).

Fortunately, a number of dedicated people have spent a considerable amount of time to make the event happen.

I’m quite excited about this year’s WordCamp UK, as a number of announcements have been made in the past week or so:

Last year’s conference was superb, and I’d highly recommend it. It was great to get a chance to meet and learn from people that are using and developing for WordPress on a daily basis. If you do decide to attend, I’ll see you there!

Update: I have closed comments on this post due to spam, but if you have something to say you can always send me a message.