UX Musings @cindook - Tumblr Blog

Remote design sprints

This week following the kick-off of a ‘discovery’ project and the customer research, it was time to pull all the insights together and move forward with the ideation part of the discovery stage.

For this project that I am leading, I have 1 other UX designer, 2 UI designers and 1 product owner involved. There are a few of us because the project spans across the products that all of us take responsibility for.

It’s important that we are all involved and work collaboratively, so I decided that for the ideation and design part of the project I would adopt some of the methods from the design sprint book by Jake Knapp.

So, last Friday following the customer research we input all our insights across the various conversations into a Miro board, using different coloured post-it notes for each participant, so we knew who said what. I ran a workshop that saw us categorising the insights into emerging themes.

Following this workshop I gave each person 3 voting dots, that they could place next to the post-it notes that they felt were most important in helping us achieve the goal of the discovery project. This activity was done asynchronously so as to give everyone the space and thinking time they needed. A deadline was set for Monday at 11am.

This Monday at 11am, I then ran a 'crazy-8s' workshop. We began by reviewing our votes and agreeing based on where the majority were clustered, the top 3 areas we wanted to continue focusing on for the rest of the discovery stage. We then allowed ourselves 20 minutes to capture down our notes around these 3 areas by looking back at all our documentation so far, again this was done separately. We then came together 20 minutes later to start a sketching workshop that saw us rapidly sketching different ideas on the 3 different topics. This is done by folding a piece of A4 paper into 8, so that you have 8 small rectangles, and to set a timer for 8 minutes giving you 1 minute to fill in each square with an idea or concept. We ran 3 of these in quick succession to keep momentum, and within 30 minutes we had completed the activity. We all took photos of our papers and uploaded them into the Miro board for all to see.

The next activity from the Sprint book is to then compile more comprehensive 'solution sketches'. We are working on this asynchronously and will reconvene on Wednesday afternoon to run an 'Art Gallery' activity where we discuss each and talk through them. Another voting session will happen after and we will continue our design from there...

I have really enjoyed taking some of the activities and ideas from the Sprint book and applying them to a project that isn't strictly a 'sprint'. I think particularly when you are remote, it would be difficult to run a sprint in the same timings as the book, due to the difference in energy required to sustain a remote call for a long time, and handle workshops remotely. You certainly need to take more conscious breaks and give people time to work away from the group as well as with when you are remote. There are also some fantastic tools out there such as Miro that can assist when working remotely. I've learnt a huge amount remote facilitation that will help me with future projects.

Task modelling

This week I attended a workshop through UX Bristol, called 'Task Modelling' run by Jesmond Allen.

I was initially drawn to the workshop because I've been interested in

Task models are diagrams showing steps people go through to complete a task. They help capture people's understanding of the world i.e. their mental model, and therefore allows us to design systems that match this user expectation.

They are particularly helpful in helping dissect a stepped process and to understand decision making processes e.g. the steps someone would go through when deciding what shirt to buy on a website.

Often there will be a direct correlation between the task model and the steps/screens in an interface (as we go about matching mental model to system model).

How do you create a task model?

1. Understand your users - you need to conduct primary qualitative research in order to understand how the people you are interested go about said task. This could take the form of user interviews (asking people to describe past experiences of doing the task), ethnography (watching people do the task) or even asking them to participate in a collaborative task modelling workshop 2. Distill the key insights from the research and start to draw a task model by writing the different steps down, and then trying to organise them with sub-tasks, ordering and groupings. Ultimately you want to end up with a task model that contains rectanges (tasks), arrows and washing machines (a pool of tasks that will be considered/done together).

For example, in the workshop we created a task model for 'making a cup of tea for a stranger'. In our groups of 5 people we conducted small interviews with each other. We then put our insights into a Miro board and organised them. If we'd had more time we would have tidied it up using arrows etc.

Here is what we came up with:

Conclusion

I will certainly look to use task modelling in future pieces of work. I have worked on similar models before using 'user story mapping' but I see a key difference being that task models are purely about mental models, where as the user story map is getting into the territory of how we plan to build a system to support the task model.

Explaining what I do

Out of coincidence, in both my current job and previous full time role the companies i've worked for have put on events that included the same external speaker. The speaker gave the same motivational talk, that touched on Simon Sinek's why? positioning, as well as talking about phrasing your job as the benefit it provides, rather than the activities that you do.

The example the speaker (whom I can't remember the name of, or manage to find through my googling) gave an example of a fireman that described his job as "I allow people to live into their future".

This idea has always stuck with me.

Most recently I have been reading 'Show your work!' by Austin Kleon who recommends you have a short and clear way to explain what you do to other people. This so that people outside your industry can understand what you do and the benefits, and therefore share this with others.

I thought I'd give it a go, here are some I came up with:

"I help technology businesses maintain and find new growth opportunities by designing valuable and easy to use services."

"I help a group of people come up with the best idea possible, by giving them all the information they need, helping them ideate and giving them real user feedback on their ideas."

"I help businesses diverge and converge on the best design solution to a problem, getting everyone's input along the way."

A designers role is to empower others to design

I have heard the concept before that the UX and UI designers should not be the only person on the product team(1).

Over the past year I have observed this concept more and more. Below are a few reasons why I believe this to be the case:

## 1. Designers do not have all the information about the problem

The designers on the team are not 'subject matter experts' (SMEs) or the customer (most of the time).

It is a designers job to talk to internal SMEs and external customers to understand the problem that needs to be solved.

Here, a designers job is to draw useful information around what the real problem is, why it's currently a problem, and understand the mental models of the intended users so as to best match that in the system. There are many techniques to doing this, from traditional user interviews, to card sorting etc.

These other individuals are helping us frame the problem, and painting a picture around which to model a solution, thereby contributing to solution design.

## 2. Designers do not have all the information about the solution

### Stage 1

The designers on the team do not tend to be technical experts or business experts.

It is a designers job to communicate effectively with these people in the team to help them empathise with the end users and understand the framed problem and the model for the solution.

The designers then need to facilitate collaborative workshops with these people to ideate and come up with concepts that they believe will achieve 4 requirements, to: * add value * be easy to use * be technically feasible * work for the business

These workshops can take the format of a crazy-8s exercise, user story mapping workshop etc.

Here, these other individuals are helping identify different approaches to the solution, and collaborating to identify opportunities that meet the 4 requirements.

### Stage 2

The next step is for designers to take these conceptual solutions and mock them up. At this point they may be applying more design, but often that will take the form of best practices and conform to common patterns that users are familiar with.

These designs are then taken into usability testing with real users. At this point the designers job is to facilitate this session in such a way that they can learn whether these conceptual solutions meet 2 of the criteria - add value and be easy to use.

The participant is helping us understand these things, and by the designer asking appropriate follow up questions, they can understand when part of the design falls down in either of these parts, any changes they could make to the design to make it better.

Here, the test participant is contributing to pointing the product team in the direction the design needs to go next. This stage will be repeated until there is little pointing remaining.

### Stage 3

When any product is being built in code, questions get raised all the time, and decisions in terms of how the system should behave in certain situations needs to be addressed.

These considerations are a collaborative discussion or activities that again pull on the expertise of everyone in the team to collectively come up with the best way forward.

## Conclusion

Designers do of course need to have good design skills themselves, and have industry knowledge of design best practices and pattern conventions, however this is arguably not the most important part of their job.

Designers work best in cross-functional, empowered product teams with access to internal and external stakeholders and customers *because* they are not the only ones designing. As a result, better products are built.

The key skills designers need to have is: * information gathering (curiosity) * information sharing (communication) * facilitation of workshops (collaboration)

An experienced designer will have many techniques for doing each of these things, and will be able to effectively apply appropriate techniques to different projects, based on the context.

#### Notes (1) By product team I mean a group of cross-functional individuals that are empowered to achieve clear goals and solve customers problems.

Facilitating kick-off meetings

Today I facilitated a kick-off meeting for a project which is going into ‘discovery’.

Discovery is a new term we are using at Kallidus to indicate a period of learning that we need to do, in order to have better clarity over what we should be developing into our products. It’s essentially taking a problem to solve and identifying a possible solution which considers business viability, usability, feasibility and value. It helps to discover how to build the right product, before we build it.

The particular project we are carrying out a discovery stage for crosses all of the Kallidus products, and so I invited stakeholders from across products that are part of the product and development teams.

The objective of the meeting was to discuss each of the problems that formed part of the discovery (there were 4 under the umbrella theme) and run through the following items:

What evidence is there currently to suggest this is a worthwhile problem to solve?

Who will be involved (stakeholders, customers)?

What are the business goals (measurable outcomes)?

What are the user goals?

What are the key workflows?

What are our success measures?

Key dates and milestones

Known risks - usability, technical, value, financial, business development, marketing, sales, legal, ethical

What do we need to learn?

Ideas for next steps

Due to having 4 different items to run through this criteria for, I popped it in a spreadsheet with each item having it’s own column and we ran down each column in turn filling it in collectively. This was done with my screen sharing via our Teams call (we’re all remote obviously!).

I had pre-filled in some boxes to make the task not too daunting and to get a conversation started.

The kick-off meeting went well, and we now have a good starting point for where to move forward from, we identified considerations that would not have occurred to me individually as a UX designer that can now been taken into account, and we included the developers so they will now feel more involved in this project (and we will continue to keep them involved).

In hindsight, the session could have been more interactive if I had instead put the ‘blank spreadsheet’ in a different tool such as Miro where people could access it and add in their own notes as we were talking. However, I don’t know whether that would have slowed us down (we only had an hour!). Definitely something i’ll consider for next time though, as we always want to make sure we are understanding everyone’s opinions, not just from those that ‘shout the loudest’. I have hopefully covered this also by asking people to reach out to me directly, or post a comment in our meeting chat if they think of anything after the session.

Our kick-off spreadsheet partially filled in:

Mental models in design

Conceptual models/mental models help people determine how we use and operate things in our environment. This a formed by understanding the affordances, constraints, mappings, visibility and implication of action for a system.

Designers create the ‘design model’ which is articulated through the system image/interface, and should align to user’s mental model to make most sense.

Designers can employ the following technique to do this successfully:

metaphors e.g. icons

consistent concepts e.g. drag and drop

clear relationships

clear mapping

There is a balance between making things visible to the user vs cognitive overload. This can be achieved by:

dividing the interface into logically arranged sections to form a structure that provides the user with necessary info at each stage

place connected concepts together

make functions obvious and transparent

provide clear and easy-to-follow instructions (where necessary)

provide informative feedback

Jobs-to-be-Done

Exploring the move from use of traditional personas to Jobs-to-be-Done (JTBD).

Personas

Personas have been used for many years in design to paint a picture of the users of a system. They have allowed designers to base design decisions around research that has been done on their users and their behaviors. Unfortunately a lot of personas are not based enough on actual research, and are also focused on attributes of the persona which are irrelevant information to design.

Knowing that a persona of your system is a male 33 year old that likes playing football on the weekend doesn't necessarily give you the insight you need to design a system that will suit them well, particularly considering it is likely that your user base is made up of lots of diverse individuals.

In addition, when coupled with User Stories, another common approach in the UCD lifecycle, the design becomes solutionised. 'As a ____ I want to ___ to that ___' leads to user stories such as 'As a user I want to set my currency so that I can pay the right amount'. No one 'wants to set their currency' really, and so because of User Stories like this designers build in functionality that users don't **want** rather than finding other innovative and better solutions for ensuring a user pays the right amount for their purchase.

As Theodore Levitt said in 1960: "People don't want a quarter-inch drill, they want a quarter-inch hole".

Jobs-to-be-Done

So, how does JTBD change all of this?

JTBD helps you understand the jobs that your product is hired to do. It guides you to have a better understanding of your users' motivations and helps you innovate. A JTBD is not a product, service, or a specific solution; it's the higher purpose for which your customers buy products, services and solutions.

Along with JTBD you can put together Job Stories, which are concise, believable, easy to understand and easy to reference statements. They follow the format "When ____ (situation) I want to ____ (motivation) so I can _____ (expected outcome)" which leads to statements such as "When I am on the bus I want to play a mentally challenging game so I can keep my brain healthy".

The JTBD technique uncovers: * Motivations - why customers buy your product * Situations - why customers switched from another product * Anxieties - whether or not customers are struggling with your product

The steps involved in following a JTBD framework are:

1. Identify high level jobs

Use quantitative data to understand high level jobs e.g. feature requests. An example of a feature request might be to have tutorials on the system.

2. Identify the sub jobs

Break down the high level jobs into sub jobs. For example, identifying the sub jobs of tutorials could include 'how to' tutorials, hints, tooltips, more descriptive text on the system.

3. Observe how it's done today

How do people solve this particular job today? Ask people to show you how it's done.

4. Conduct JTBD interviews

Conduct interviews with your users and have them tell you the stories of how they decide and purchase a product.

Try to flesh out a timeline of 'first thought' (the moment your customer thinks about switching from old to new product), through to passive looking, active looking, deciding, buying and consuming, based on their past experiences.

Uncover the four forces: 1. Reason to switch: Problems with the current product 2. Reason to switch: Attraction of new product 3. Reason to stay: Existing habits and allegiances 4. Reason to stay: Anxiety and uncertainty of change

As questions like: What tool were you using when you started looking? Tell me about the old solution, can you remember how well it was working? Can you remember if anyone else was with you when you started looking?

This is so we can understand the answers to questions like: Why do people hire our product? How can we make sure no one switches away? Do we need to iterate or innovate? What are customer's motivations behind using our product?

5. Write job stories

In the format mentioned above

6. Develop solutions

Using the job stories develop solutions that will solve users needs.

Conclusion

Jobs are the emotional struggles customers face to better their lives. It is what's motivating them to seek a solution. It answers 'why', not 'how' or 'what', for example: help motivate me, make me feel accountable, put me in control of my health.

Jobs are higher level and are abstracted from the solution entirely. Tasks are about functionality within a new or existing solution and serve no purpose in the discovery and design phase of a project. Jobs come out of research and via design they turn into tasks because the designer has then specified functionality to solve the job. Tasks are useful for developers to create user stories from.

In addition, JTBD focuses the design team on asking why to really find out emotional needs. However, asking why is not about the destination but rather the journey, and there is only so much insight you can get before it becomes to abstracted. To stay on track, one should focus on 3 layers: 1. The immediate layer - usefulness. What do you actually do with the thing? 2. The secondary layer - usability. What result comes from using it? 3. The tertiary layer - desirability. What's different now that i've accomplished my goal? (what is the outcome)

Sources: https://jtbd.info/penn-jillette-gets-jtbd-4bdd9c4373c0 Intercom on Jobs-to-be-Done https://www.intercom.com/books/jobs-to-be-done

#jtbd #UX Design

The Simplicity Imperative: What Responsive Design Can Teach Us About Any Design Work When designing an experience for all screens and all devices, fingertips...

Simplify your design (modular design)

Simplify your team (be lean)

Prioritise prioritisation (’mobile-only’ your MVP)

Iterate on fidelity, not functionality (agile done right)

Make time for simple (UX waterfall or ‘double sprint zero’)

Interaction Design Foundation - Mobile UX: Week 5

Week 5 of the IDF Mobile UX course provided some useful additional information for designing mobile interfaces:

A mobile splash screen is the first screen a user sees when accessing an app. It is best practice for them to introduce the user to the first screen of the app, while making it clear that progress is being made on loading. It should not be used for marketing or branding.

When a user needs to create an account/profile on a mobile interface, only ask for information that is essential (to the business or app) to reduce the amount of user input

Usability considerations when implementing maps in mobile designs:

Scrolling and panning - add borders around the map so scrolling of the map and page are distinct

Pinpoints and target sizes - ensure your target size is big enough for touch. If this isn't possible because there are multiple pin points in the same place then use another element e.g. grouping the pins which on tap reveals a contextual menu to pick an individual pinpoint

Network connection - slow connection can cause frustration when zooming and the map not loading/responding quickly enough. Always allow an easy way for a use to switch to a list view to view content.

Use gesture controls to add extra functionality to the map without cluttering the interface with extra buttons (that need to be min 40 x 40px)

Allow for help and escape

Best practices for providing help in mobile applications:

Help and support should be easy to find e.g. in tool or tab bar

There should be more than one form of help e.g. self service FAQs, contact form, phone number etc, video tutorials, notifications

There should be an introductory tutorial when first interacting that a use can skip and come back to later

In app help should be provided for new features or when a user accesses a particular functionality for the first time

Help videos should be able to be controlled by the user

User demonstrations, tutorials, single screen overlays, walkthroughs, tips, single screen summaries

Patterns for mobile search:

Auto-complete

Dynamic search (results are changing as you type)

Explicit search (requires an action to start the search)

Faceted search (filters etc)

Saved and recent searches

Scoped search (user defines criteria before starting search e.g. image, web, news on google)

Search forms (multiple fields e.g. flight search)

Search results (different formats and allow user to switch between)

During user testing, ask users to perform tasks 'What would you expect to happen here?', 'Tell me what you are thinking and feeling'

#mobile ux #ux design

Interaction Design Foundation - Mobile UX: Week 4

Week 4 of the IDF Mobile UX course focused on common mobile design patterns:

There are core differences of user behavior between smartphones and tablets:

Smartphones are more mobile, have more distractions, have smaller resolutions, users are often multi-tasking, associated with a deep social/emotional context, have less controlled lighting

Tablets are less mobile, more around fixed movement, 65% are consuming at home, it's a multi-user device, has a higher resolution

For mobile you should minimise detailed manipulation in favour of tappable visual choices (the tappable area should actually be the same size or bigger than the visual element, and there should be enough space between elements to cater for this)

Portrait mode on smartphones is viewed by default

When cradling a phone and interacting with one thumb, the top left ocrner and bottom right hand corner are hard to reach - design for the easy to reach areas

Design with content first and navigation second

Common UI patterns on mobile devices:

Left channel navigation on tablets (aligns to mental model of desktop software)

Back on top left screen

Default fields should be based on context

Smartphones are the preferred platform for users ages 18-34 but for those younger and older, tablets are preferred (because they are not 'on the go', have a bigger screen size)

Smartphones are used more regularly than tablets but for shorter periods of time

There are some common issues that mobile users encounter:

smaller bandwidths for data transfer

no keyboard (keyboard on the touch screen is difficult to use and inaccurate)

no mouse

small screen real estate

Cognition

Mobile comprehension is at least twice as hard as on desktop. When you can't see much of the content you rely on memory to keep the content alive and you navigate around the screen more, which can lead to distractions and takes extra time. To get around this, simplify content on mobile and use plain language

Visualizations help communicate large amounts of data, uncover complexity, helps understand 'what-if' situations, identifies hidden patterns, permits gradual discovery, provides immediate insight. Design visualisations by:

Use high contrast visuals

Support native gestures on infographics (progressive disclosure)

Use visual metaphors (Skeuomorphism)

Make the main task apparent

Voluntary and involuntary attention using visual cues (movement, orientation etc)

Skeuomorphism

We perceive the world as a set of affordances. An affordance is an object that's shape suggests its use eg. door handle. Skeuomorphism represents 'perceived affordances' and fits with our natural interpretation of objects but in a digital world

Flat design has taken over from Skeuomorphism, free from clutter, and exploits the digital interface for its own strengths

The current trend in smart watches has seen a return to Skeuomorphism

Don't make me think

Usability is key

Make things self-explanatory

Don't make anyone think

Don't waste people's time

Let users go back

People are habitual

Get to the point

People love search

Show them how to get home

Learnability

Learnability must be easier for apps that are not used as regularly, as people won't put in as much effort to learn these

Learnability can be in proportion to cost (a user is more likely to invest time learning to use something if they spent a lot of money on it)

Learnability can be affected by comparing to competitor products

Learnability will reflext complexity

Areas of UI that help learnability:

Action bars

Big buttons

Notifications

Dicoverable controls

Common UI patterns:

Pull down to refresh

scroll horizontally

floating context menus 'just in time'

transition hints (animation)

Content first: Copy -> UI elements -> interaction -> media

Operating systems

Different OS support different gestures. If designing a responsive website, design for those common gestures

Remember 'hard-keys' on devices e.g. apple home button, android back etc

Review iOS, android, windows etc design guidelines for specific details when designing native apps

Designing and building a responsive site provides:

one set of code to manage

avoids needing an app

avoid bad m. site

future friendly

addresses accessibility

addresses inter-operability

provides context sensitivity

Native apps:

+ access functionality of the device e.g. gps

+ more likely to run without error

- can only run one OS

- more expensive to develop each OS separately

Hybrid apps:

+ Single standard code language, then compiled for each platform

+ more cost effective

- higher maintenance costs

- not all native interactions can be used

- won't follow all OS guidelines

Social opportunities include activity, status, content of others (anonymous or not), like, location based content

#mobile ux #ux design

Interaction Design Foundation - Mobile UX: Week 3 (Part 2)

Week 3 of the IDF Mobile UX course was FULL of valuable take aways - it’s not often I take so many notes!

My take aways from Week 3 of the IDF Mobile UX course:

Mental Models and Cognition

Skeuomorphism is the design concept of making items represented resemble their real-world counterparts. It reduces cognitive friction because users can take cues from what they know in the real world and apply it to digital e.g. floppy disk = save, bin = delete

Cognitive friction occurs when a user is confronted with an interface or affordance that appears to be intuitive but delivers unexpected results. It's important to test the interface to ensure they match user expectation.

Avoid cognitive friction by

Conducting user interviews to understand how a user wants to undertake a task (mental model)

Conduct user testing during wireframing and prototyping

Design task flows, in the simplest way, with the most amount of automation

Have a simple IA

Perform a heuristic review/evaluation

Mental models if based into a design form a conceptual model

A mental model is the expectation a user brings to your design, based on past experiences and any assumptions they have. It is when people construct 'small scale models of reality' to anticipate and explain events.

Mental models can evolve

Use mental models to understand what a user believes about any given system or interaction. Tapping into a user's mental model allows the product to communicate the function through form.

Users expect functionality to be consistent with previous experiences they've had (promotes use of standard UI patterns)

Users mental models can often be confusing/wrong

There is a level of inertia to overcome to alter someone's mental model - it must be a 'high value' outcome for the user to want to change

The best way to help users shift their mental model is by providing instructions, labels, tutorials and visual cues in the new model

The conceptual model of the system should match the mental model of the user

A conceptual model shows in diagram form how the application will work. It allows you to see the tasks a user can perform, all the objects in the system (including any actions, attributes of them and the relationship between them), and helps you streamline your terminology.

Personas

Personas and scenarios are tools for guiding empathy in design, improving design decision making

Personas are empathy capsules, bringing together all the emotional, social, physical, workflow needs of your users, that can guide your design (they include roles, goals, tasks etc to provide empathy and insight)

Through qualitative user research e.g. field study, contextual enquiry, ethnography we can find out what our users needs and goals are (not what they tell us they are). This should be done in their natural environment

Give personas a role name (e.g. Support Seeker Sally)

A good persona should elucidate observations from research, focus on the 'now', be realistic (not idealize) and help set the ground work for the UX design task

A user persona helps you understand

The context in which the product will be used

The behaviors of the users at the moment

The attitudes of the users

The wants/needs from the product

The difficulties the user wants to overcome

The objectives they have

Personas can be used to validate design decisions, develop priorities when ideas conflict, as a source of inspirations, keep focus on the user

Tasks

A task is the need of a user expressed as a design element

Task orientated design is UCD

GOOB (get out of the building) and meet potential customers and learn to understand what problems they are looking to solve in their lives. Then design solutions to those problems that are meaningful and cost effective

Performing a task analysis lays out tasks from a users perspective, and is agnostic of the current situation and technology used (sometimes called user scenarios)

When observing users in task analysis research consider

The ignition point - what prompts them to begin a task?

The focus point - what will tell the user that they task is finished?

What knowledge does the average user have when they begin the task?

What additional knowledge do they need to reach the focus point?

Which tools, processes or info will the user utilise during the completion of the task?

Document task flows using post it notes at a high level then add details and include

User groups - actions the user will carry out

System groups - actions the system can carry out for the user

Object/tool/info groups - requirements of the user to carry out an action

Question groups - unresolved questions/difficulties with the task

Optimise the task flow by reducing the number of steps and switch user action to system actions where possible

Remove as much complexity from the system without over simplyfing (and compromising on functionality)

#mobile ux #ux

Interaction Design Foundation - Mobile UX: Week 3 (Part 1)

Week 3 of the IDF Mobile UX course was FULL of valuable take aways - it's not often I take so many notes!

My take aways from Week 3 of the IDF Mobile UX course:

Mobile Usability Best Practices

It's important to maintain flow on small screens

Goals of the UX are

Easy to use (clear controls, easy to find content, intuitive, loads quickly)

Easy to learn (short learning curve, confusion minimized, clear shortcuts, rules and routines)

Satisfying (loyalty, enjoyment, low stress)

Avoid friction (avoid changing rules, flow or rhythm, not too much reading or scrolling)

Task orientated design focused on task the user wants to complete

Mobile design should be visual

Consider offline/online state behavior on mobile (core content should be available even when offline)

Follow mobile best practices with regards to layout, tasks, navigation, visual and controls

Context is key when designing for mobile - what else are they doing? what else are they holding? where are they? what time is it? are they techincally savvy?

Fat finger friendly - CTAs 44px x 44px minimum for iOS and 48dp for Android

Important CTAs on the screen should be sticky

No long wait times for loading content

User clean layouts - visible and intuitive controls, back buttons, icons, navigation

You don't know your users screen size, so your design needs to work across all sizes. You can design by grouping devices of similar screens sizes and choose break points, define content rules and design adaptation rules that enable you to display things well on each group of devices, adhere to WC3 web standards, consider different browsers.

Keep navigation simple for mobile by prioritising key tasks/key user journeys, have a flat structure (no deep hidden content), clear labelling and touch screen friendly CTAs

Keep content to a minimum for small screens, and don't include any which is not supported by some browsers/devices

Reduce user input - keep URLs short, allow alternative input e.g. voice, short forms, controls such as steppers rather than keyboard input, have easy/permanent sign in.

Be considerate of connection - retain data, reduce page size, reduce image sizes (and no. of images)

Design for continuous experiences across devices by maintaining continuity (all data should be available on all platforms), consistency and brand

People use their phones in 68% of cases at home

Half of all smartphone users consider their phone to be their primary access point for the internet

77% of smartphone use is for socialising, shopping and 'me time'

Test mobile device designs using the one thumb, one eyeball (because they are distracted!) test - users should be able to perform tasks in under one minute

Mobile interfaces have far more input options, so which ones the user can use should be obvious by providing affordances

Text should be a minimum of 11pt and consistent. Contrast between text and background is key in bright lights

Forms should follow the rules:

Labels above field or floating

Mandatory/optional fields clearly labelled

Form fields validated on the fly (not all at end)

Cursor auto in first field with correct input keyboard

Use alternatives to dropdown e.g. stepper

Use native calendar picker/slider etc

URLs should not show as underlined text, use a button instead

Don't send a user to the browser by use an in app browser (keeping them in app)

UI elements that work on mobile, won't necessarily work on desktop and visa versa

#mobile ux #ux

Interaction Design Foundation - Mobile UX: Week 2

My take aways from Week 2 of the IDF Mobile UX course:

Delivering a mobile web experience provides you the opportunity to cater for the specific users' needs at the right moment and in the right place.

The mobile web can be accessed in places where the internet is not easily accessible from other devices, and provides a large user base and wide geographical area (particularly in developing nations).

Josh Clark talks of 3 categories of mobile web access: micro-tasking (interactions for brief but frenzied periods of activity), local (interested in what is around them), bored (entertainment).

In developing nations it is common for people to only be able to access the web via their smartphones. Even in the developed world more than 50% of online interactions are carried out with smartphones.

On mobile devices, you need to ensure content is minimal and delivered by priority to the user

Mobiles have GPS, accelerometer, pedometers, touch screens, gesture controls, voice user interaction, eye tracking etc that don't exist on desktops, which allows you to deliver better experiences.

"Content is King" - you need to understand what content needs to be shown before you can design (understand your users's needs).

It is important to take both a content first and mobile first approach to web design.

Principles that apply to mobile:

Provide feedback to users on progress via haptic or visual cues

The experience should be seamless across devices

Ensure CTAs are big enough (min 40x40px) and are limited as much possible

Controls should be where a user can reach them with their thumbs (towards the bottom)

Reduce user input where possible

Ensure gesture navigation is discoverable

Ask confirmation from the user when necessary

Allow the user to stop their interaction, and come back later and be able to pick up from where they left off

First time access and navigation should be intuitive and easy

Deliver content that is important in this context

Navigation should be simple with the aim to reduce the number of clicks a user has to make to perform a specific task

Research techniques apply to mobile as they do to any other device, but that research needs to appreciate the context of use for mobile.

To simulate real lift in a testing lab for mobile, have music on, use stop-start techniques, use treadmills, get them to walk around obstacles, as this all helps the user capture that changing context.

It is difficult to test lo-fi mobile prototypes for gestures, so this needs to be done at hi-fi stage.

#mobile ux

Interaction Design Foundation - Mobile UX: Week 1

I’ve just started a course with IDF and chose to do it on Mobile UX just to brush on some skills. Here are my key take aways from Week 1:

Task orientated design is particularly important for mobile where there is limited space, consider what the user will do with the application on particular devices. Task analysis should be done in the early stages of design to understand this (user research).

Use adaptive design or responsive design depending on the type of application and whether the user will require different functionality depending on the device and the context they are in.

Smart phones are used for shorter intervals than desktop/laptop/tablet, often while multi-tasking.

The keyboard when on a mobile is limited and the tasks executed are less complex than if using a desktop etc.

It’s important to understand the users’ mental model of the task/situation so that this can be replicated in the interface.

Mobile is more heavily used for social and entertainment activities.

The mobile context is largely going to be different to the desktop context.

Context should be understood by considering culture, environment, the activity, the goals, the task,the attention span, the device, the connection.

Applications need to work across devices, without breaking the user journey.

Increasingly the lines are being blurred on where devices are being used and in unison. See device as “I want to check” - mobile, “I want to manage” - desktop, “I want to immerse” - tablet.

In many markets now, smartphone access to the web is much greater than traditional PC access.

#mobile ux

Wurman took and ran with this as permission to be an architect in all things. To continue calling himself an architect. In his introduction to Information Architects in 1995, he says “I mean architect as in the creating of systemic, structural, and orderly principles to make something work — the thoughtful making of either artifact, or idea, or policy that informs because it is clear.” The medium isn’t what makes it architecture or not. It’s the systems, structure and order in space that makes it architecture.

https://medium.com/@danklyn/2017-information-architecture-summit-closing-plenary-address-efb0e0e21d2c#.dhgofo6l9

#information architecture

The Future of Product Design

O'Reilly have some really awesome free resources. Most recently I have been reading their e-books and reports, one of them being 'The Future of Product Design' by Jon Follett (http://www.oreilly.com/design/free/future-of-product-design.csp).

I've made some notes on my key highlights from the e-book:

* How we create products (both physical and digital) has completely changed over a short period of time due to the democratization of innovation, compression of design cycles and the reshaping of the relationship between consumer and product.

* The future will see mass customisation with highly targetted, rapidly developed and less wasteful products.

* The barrier of who can design new products has lowered due to enablers such as crowdsourcing and open source technology. It allows people to build upon things that other people have done.

* 3D printing is making prototyping cheaper and quicker.

* Software moving from assigned seat licences to subscription based models is making it cheaper for people to use it.

* Once a product has been tested, there is still the complexity of navigating mass manufacturing, with increased complexity and more difficulty in ensuring quality control.

* Changes at the mass manufacturing stage can be expensive (steel moulds that are commonly used are expensive to re-make as they can't be re-moulded).

* Hardware such as the Raspberry Pi and Tessel 2 have made it cheaper and quicker to ship products by using these off the shelf products, particularly if the volume isn't so big.

* Enterprise companies can still innovate while keeping risk low by acquiring start ups or creating internal incubators and performing pilots of small runs of products.

* Products should not be thought of as finished but representing a living relationship that is never fully complete.

* Understanding the users of a product, and their motivations, is becoming increasingly important.

* Designers need to understand emerging tech capabilities, then understand how they can better enable customers, to then define that user experience.

* We need to think about what happens to the product once people stop using it, including sustainability and environmental impact. For example, but selecting materials which are environmentally friendly such as biodegradable plastics.

#product design #UX Design

Involuntary and Voluntary Attention

I recently went to a meetup about UX and Psychology. It was refreshing to hear from a current student of Psychology about real research insights into how users behave.

The talk was focused around both involuntary attention and voluntary attention.

Involuntary attention

A designer can create involuntary attention by introducing features which produces a salience hierarchy, and therefore attention flow (from most salient to least salient). This attention flow can be utilised to aid cognition for the user.

Different types of features can be seen in the slide below, and include:

Colour

Colour contrast

Saturation

Orientation

Motion

Clear contour

Dissimilar to surroundings

Words

Object centre

Human/face

Signs

Voluntary attention

A designer can create voluntary attention by introducing attributes and 'pop up' effects.

Different types of attributes can be seen in the slide below, and include:

Colour

Motion

Orientation

Size

Luminance onset

Vernier offset

Closure

Luminance polarity

Curvature

Topological status

So, with all elements on a screen/interface, you can choose to allocate attention to it. The type of attention you allocate to it (voluntary or involuntary) will depend on the context in which the user is in. Do you already have the users attention e.g. reading a text book?

As UX designers we should always be using these techniques for good, to ensure the user understands correctly (the truth) and is able to perform a task they want to do, in the easiest way possible.

With this in mind, we should not strive for all elements on an interface to be screaming out with features and attributes, but rather make mindful decisions as to which elements should do, in order to aid the user. It is this contrast between those that do and those that do not, which allows the user to take notice (involuntary attention) and help us guide them to what they want to do.

#ux #pschology

Trending Blogs

Recently Viewed Blogs

UX Musings