- Users are just like us. They have other things to do and don't have time to spend learning new features, most of which they probably won't use
- If you want to learn what people really want, don't ask them, ask them what they do and how they do it
- Shadowing users is the best way to find out what the user really does and how your application can make it easier for them
- Personas - is a user profile focussed on goals and activities and sometimes demographics but usually less so
- Adding a name and a face helps lock down who a user really is making them less open to your own interpretation
- You don't want any more than 3 or 4 personas and you should create a primary persona
- That primary persona is the one that absolutely has to be satisfied for your product to be a success
- Users goals don't have anything to do with your web app. We have to understand why users are using our apps? Is it personal satisfaction, is it their job, is it reward/recognition?
- Goal directed design means listening to users and understanding what they need and creating applications from an informed perspective
- Drawing a task flow is often more useful than personas. It will help highlight how a user will move through your application and complete tasks in an application from beginning to end
- Creating use cases is a great way to expose the step b step processof how an interaction or a task might be accomplished
- Step 1 do this, step 2 this happens, step 3 do this, step 4 this happens
- Use cases also need to include exceptions and detail what happens if the main use case cannot be followed. e.g catching errors or invalid data
- Apply Kaizen to use cases. Go back over every use case and rework it, to find a way to do things smoother, faster and more obvious
- Kaizen is Japanese for "Change for the better"
Only build what is absolutely necessary
- Often web apps evolve based on demands of users. This creates a problem
- Usually when you always build exactly what users ask for, you end up with a bunch of features only used by 10% of your users
- These features get in the way of 90% of the features that are used by most users
- Don't compete with competitors based on features.
- Alan cooper said this is like running through the battlefield underfire. You can run all you want but you have to keep firing to make any progress
- It's also exhausting for users constantly having to learn new things when they just want to get things done
- Complete the unnecessary test. Go through every single feature and ask yourself what is really necessary
- It doesn't mean you go and remove all these features, it simply means you recognise what you've done and avoid doing it again
- Another approach when building new applications is the 60 second deadline.
- List out all the features and then decide which of those features you MUST keep in 60 seconds
- You'll then be left with all features, essential and nice to haves
- Less is more. Pareto principle in web applications - 80% of an applications usefulness comes from 20% of it's features. 20% of development produces 80% of the app means that 80% of development time is spent satisfying 20% of the users!
- To create focussed applications, focus your efforts on 20% of features that are essential and you'll take care of 80% of your users
- You can always re-evaluate nice to have features after app is build
Support users mental model
- A mental model is generally what we believe to be true based on our experiences
- Developers love to expose every possible setting to users
- When building features, think about the users mental model and how things might actually happen in real life
- User wireframes to nail things down
- When creating wireframes, consider the three R's Requirements, reduction, regularity
- Requirements - stick to them and don't allow nice to haves in the early phases. Less there is to know, the easier an application is to understand
-Reduction - Reduce interfaces to their core as much as possible, reduce clutter, redundancy, user error, verrbiage
- Reglarity - Do things intentionally, same fonts, size, form labels, colours, spacing
- Provide good defaults and a good starting point rather than forcing users through a complicated set up screen.
- Let the application explain itself to the user through usage
- Before handing over wireframes for approval/discussion, practice kaizen to try and find ways to make improvements
Test it out
- The no. 1 way to find out about the user experience of your application is to test it out
- Try the browserless test, hide all the browser tools and see how easily users can move around without using forward and back buttons
- The 5 second test. Show users a list of different screens and ask them to tell you what they remember, keeping a record of it
- Contextual usability testing is allowing the user to interaction with an application without telling the you're taking metal notes about what they're doing
- Eat your own dog food - use the products you create as rigorously as your customers
Turn beginners into intermediates immediately
- Skill level of applications does not break down easily to beginner, intermediate and advanced users
- The vast majority of users will always be intermediate and so you have to get them up to that level as quickly as possible
- Users don't stay at the beginner level for very long, even right at the start
- New user wizards are generally a bad idea as you're asking users to configure something that they are not sure how they'll use and whether they'll be able to change it again
- Don't provide welcome screens, provide in context help about what can be done in different sections
- Don't show people blank slates. Instead show them good examples that will encourage them to get started
- Users don't typically like to customize web apps as much as we like to think. Most users will stick to whatever defaults are offered. CHOOSE GOOD DEFAULTS!
- e.g Google doesn't ask what kind of search you want to run (Most people want to do a text search and good makes it easy to switch to others, like images, if you wish)
- Provide help docs for experts as they are the ones that will actually read it.
Handling errors
- Poka-yoke is Japanese for mistake proofing. We need to apply this to the web
- Prevention - prevent errors from ever happening like the hole in the sink that stops the sink from overflowing
- Detection - When things go wrong, detect the error and help the user fix it
Design for uniformity, consistency and meaning
- Proportion - the size or quantity of certain elements compared with others
- Alignment - Things that are related should be aligned together in groups
- Spatial memory - The ability to recall where physical objects are in relation to other objects. E.g we fumble around the room in the dar but can usual still find the light switch
- Users often navigate through pages using spatial memory after they have visited it a few times
- Consistent layouts support spatial memory behaviour
Reduce and refine
- Try to reduce pixels to data. Data/content is the most important part of the page
- Minimize copy by avoiding happy talk, move instructive copy into "Whats this" popover& write vigorously
- User white space. Studies have showed this increase enjoyment for users
- Sometimes white space is better than a graphic divider as users still understand the division and don't have to process the graphic
- Think about the number of screens a user must visit when doing repetitive tasks. Try to decrease the number of screens!
- User inline editing as much as possible to avoid forcing users into a read/edit mode
- Practice kaizen to stop you from worrying about getting the perfect solution first time around, making sure you get stuff out
5s approach
- This is another Japanese improvement process
- Seiri (Sort) - what tools can be kept and what can be thrown out
- Seiton (Straighten) - arranging things in their most efficient and accessible arrangement
- Seiso (Shine) - Keeping clean, tidy workspaces
- Seiketsu (Standardize) - leveraging standards to enable consistency
- Shitsuke (Sustain) - sustaining the work of each of the elements from the 5s
Finally
- No one has all the answers so don't be afraid to make decisions
By Jonathan Clift, a UX Desginer based in the UK.