The term 'User Experience' is predominently used in the IT industry to describe the process of designing a solution based on a set of requirements. The 'User Experience' covers all of the proceeses on the user journey, from the marketing information, to opening an account, accessing the product and the support team. It is important that the user experience is consistant across the product. The user experience can be the deciding factor in the decision to use a product, or the reason why they use a different one.
The design of the user experience is an excercise in logical thinking - its about creating processes that solve problems and enable a user to complete an objective. The process is as simple as you make it, and I do find that many of the new methodologies that have been introduced in the last few years complicate what, in essence, is a straight forward operation. The method I typically use to define the user experience is as follows:
- Consult with Clients/Product Owners to get a background on the project and their expectations
- Speak to subject matter experts and put together a set of high level requirements (HLRs)
- Agree the HLRs and start to gather the requirements that relate to the user experience. See 'Gathering UX Requirements' below.
- Organise and host a workshop with the stakeholders. See 'UX Workshops' below.
- Start to conceptualise the solution based on feedback from users and workshop. Prepare several concepts that illustrate variants of common use cases. See 'User Interface Design'.
- Conduct itertive reviews (using wireframes and prototypes) to illustrate the user interaction. See 'Prototyping and Proof of Concept'.
- Document the final solution. See 'Documenting the UX' below.
A good user experience is one which enables the user to complete a task without fuss, the need for assistance, and without any unexpected actions. As you will find if you read the information this site, a UX and more specifically, the User Interface, can be complex, multi-layered entity with many elements and rules that need to work in harmony. A good design marries all of these elements, requirements and functionality in a single fit for purpose solution.
At this stage I would like to descibe some of the key factors in the design of the UX, as they help me during the requirements gathering process. The UX has many elements but I have chosen 4 key constituents; Usability, Perception, Design and Accessibility.
|
When it comes to designing online applications, user interfaces and web services, Usability is the most important element of the design as it defines how we interact with the user. It doesn't matter how nice the product looks, or how accessible it if if its not usable. In plain terms usability is ensuring that the solution is fit for purpose for the intended audience. So this is where it can get complicated as usability can mean different things to different people which is why it is important to understand the user and design it for them (don't fall into the trap of designing it for your boss or the client). More on that in 'Gathering UX Requirements'. So what does this mean? Well, to start with, it means a usable solution must:
One of the principals we adhere to is that users does not like to learn, they want the process to be self explanatory. There is an excellent book called 'Don't make me think' by Alex Krug which was a UX Designers bible back in the noughties. There is an excellent book called 'Don't make me think' by Alex Krug which was the UX bible when I was in short pants. Refer to the 'Gathering UX Requirements' section for more information on these points. |
 |
Case Study - Hosting UX Fundamentals presentations
Introduce the Product Managers to a user-centric design approach, self assess their products and create enthusiasm within the team.
In my role as UX Designer I am often asked to present the subject of User Experience to a wider audience, and I have a variety of different presentations such as User Interface Design, User Interaction and UX Analysis. One of my favourites is Understanding the User which is an insight into how the user thinks. In this I give an overview on how users view websites, how the mind fills in blanks and how we can use objects on the screen to emphasise areas of the site. I cover eye tracking, click mapping and a few other methods we use to gather information about the users. It is surprising the number of people who leave these sessions with a new mindset and way of thinking about thei job, particularly the Business Analysts and Product Managers.
|
So you think you know your users? Well, you may know how they work, the PC they use and their favourite brand of coffee, but there are a number of traits we all have that affect the way we use technology and do our work. A common one of these is Perception, and a lot of very clever people spend time researching Human Computer Interface (HCI) and learning about the habits of users in certain scenarios, and some of it is very surprising. To design a fit for purpose solution you obviously need to know the requirements, the scope, the technology, the usability issues and so on, but there are other skillsets that a good designer must understand the user. My background is in advertising, where perception and psychology is a key factor in the design.
Obviously the UX Designer doesn't need to sit with the user and discuss their life issues, but it is useful to know how they use technology, the types of websites they visit and there knowledge of the data they work with as this needs to be factored into the design. |
One of the first things I learnt as a User Interface Designer were the Gestalt Principles of Perception (above) which describe how users perceive objects on a page. This illustrates how many simple tricks that the designer can put into the design to make it more usable.
|
A lot of people think that design is all about appearance and what the products looks like. While this does play a part in the perception of the user, as a site that it laid out well and looks attractive can seem more professional, and the user will assume that the data on the site, and the user experience will equally be better. There is a a rule called the 'attractive bais' that states that peoples are drawn to beautiful things. Whether we like it or not, its human nature so the kerb appeal of an application can have the same effect. I left Art College back in 1988, after studying Graphic Design for 4 years, and worked my way round the design agancies for several years before getting into UI and UX so I have an educated opinion on this subject, and I firmly believe that the design and the 'beauty' of the user interface has a direct bearing on the user experience. Seems like common sense but it is surprising how many organisations cut back on the UX Design when they are cutting costs on a project when, in actual fact, the design is vital to the saleability of the product. |
 |
|
Accessibility is the word used to describe whether a product (for example, a website, mobile site or application) can be used by people of all abilities and disabilities. For instance, a website is accessible if all people, including disabled and elderly people, can use it. To help achieve this there are several bodies who have created a set of Acessibility Guidelines that are used throughout the industry. These are called the WCAG (Web Consortium Accessibility Guidelines) and define the basic rules around designing and developing content on the web. In most organisations the UX Designer is considered to be the steward of the WCAG guidelines, and is generally required to specify the level of accessibility compliance as part of the UX Requirements. I am fully conversant with the guidelines and the updates that have been made since they were published in the late 90's, but I am also conscious that the responsibility for implementing them into the project is shared across the project team. So the guidelines have implecations across the lifecycle, with the UX designer needing to ensure that the product can be used by all, the developer needs to ensure that the code is written and structured in a way that is can be used with assistive technologies, and the test team need to ensure that the product has been accessibility tested. |
 |
There are many types of workshops that can be used during the project lifecycle. It is important to have a clear understanding of the workshop objective, the information that needs to be collected and the people/resources needed.
So we all know that meetings are essential for a project and should be held regularly, particularly when we move into the build phase. But we also know that meetings can take up valuable time and are not always productive. A workshop is not a team meeting, a presentation or a chat about the product. It is a structured session, usually interactive, with a specific objective and agenda and the attendees are encouraged to join in and not be too 'judgemental'. Workshops can take place at any time in the lifecycle and used to discuss any topics associated with the project.
On this site I am going to concentrate on 'UX' Workshops which are sessions that are setup with the objective of gathering information, feedback and insight on the design of the UX and the UI. There are several types of UX workshops that I recommend during the project, each of which has a different agenda, objective and participants:
- Project Initiation Workshop
- UX Requirement Gathering Workshop
- User Evaluation Workshop
Case Study - Interactive Workshop
Introduce the Product Managers to a user-centric design approach, self assess their products and create enthusiasm within the team.
I started with a presentation which ran through the fundmentals of UX, and the benefits it provides. We then moved to an interactive session using interaction modelling. The idea of this excercise is to promote out of the box thinking, and look at out products from a different viewpoint. I split the attendees into 3 groups and gave each of them a different task. Each task consisted of creating their product using a specific interaction model. For example, one of them might have MS Outlook as their model so they have to design their product using Outlook as the model, another might have BBC, and another might be a computer game. This allows them to look at the user journey in a different way but with the same objective.
The attendees found the session enlightening as it gave them an insight into the use cases and what is was about their product was really important. This led to the idea of a product portal and the design of a new generic front-end.
Case Study - Initial Workshop
Prepare and manage an initial workshop with the client.
One of my larger projects was for the newly created Tesco Bank and their online loan decisioning workflow tool. This is used by their Underwriters to assess financial risk and make an accurate decision of an individual. As the client was located in Scotland, and this had been chosen as the location for the initial workshop, I studied several credit application sites, the data that was used in the decisioning process, and the tools generally used by underwriters. I realised that the output from this meeting had to be comprehensive and provide me with enough data to prepare an initial user journey flow.
Due to my preparation beforehand, this session went very well, and the fact that I could make informed decisions reassured the client that the design would cover the main elements of interaction. We have all heard the saying "Failure to prepare is preparing to fail" but that is certainly true when it comes to workshops.
|
I am a firm believer that every project needs to have a workshop at the start so everyone is clear about the objective, can ask any questions and point out potential issues going forward. The attendees for this workshop are likely to be the main stakeholders; Project Manager, Project Owner, Project Sponsor, Client. It might also be useful if there is a representative from the teams that might be required fir the project such as an Architect, Developer, Analyst, etc. The types of qustions that maybe asked during this session are:
Once we have an idea about what the client wants we can do some 'ideation', meaning we can discuss the high level requirements and agree on the likely path to implementation, the initial tasks and a date for the next session. |
 |
Case Study - Preparing and managing an Interactive Workshop
Introduce the Product Managers to a user-centric design approach, self assess their products and create enthusiasm within the team.
I started with a presentation which ran through the fundmentals of UX, and the benefits it provides. We then moved to an interactive session using interaction modelling. The idea of this excercise is to promote out of the box thinking, and look at out products from a different viewpoint. I split the attendees into 3 groups and gave each of them a different task. Each task consisted of creating their product using a specific interaction model. For example, one of them might have MS Outlook as their model so they have to design their product using Outlook as the model, another might have BBC, and another might be a computer game. This allows them to look at the user journey in a different way but with the same objective.
The attendees found the session enlightening as it gave them an insight into the use cases and what is was about their product was really important. This led to the idea of a product portal and the design of a new generic front-end.
|
Gathering the requirements is a key part of the process as whatever due diligence we do at this stage will define not only the design of the solution, but the decisions about the architecture, build, test strategy and scope. The section on Gathering UX Requirements gives an overview of the elements that may need to be specified. The level of responsibilty for the UX Designer may vary at this stage. I am used to working in a large organisation which has project teams that include a variety of members including subject matter experts, business analysts and technical leads. I am used to working with the team, particularly the BA on the gathering of the requirements and the prearation of the requirements catalogue. |  |
|
Workshops are important to this process and I would often have different meetings for the different parts of the lifecycle; meet with the developers to discuss the build strategy, the compliance officers to define their involvement, and so on. As with most workshops, I like to keep these sessions fairly informal but the agenda and objectives are generally the same:
Once we have an idea about what the client wants we can do some 'ideation', meaning we can discuss the high level requirements and agree on the likely path to implementation, the initial tasks and a date for the next session. |
|
Case Study - Preparing and managing an Interactive Workshop
Introduce the Product Managers to a user-centric design approach, self assess their products and create enthusiasm within the team.
I started with a presentation which ran through the fundmentals of UX, and the benefits it provides. We then moved to an interactive session using interaction modelling. The idea of this excercise is to promote out of the box thinking, and look at out products from a different viewpoint. I split the attendees into 3 groups and gave each of them a different task. Each task consisted of creating their product using a specific interaction model. For example, one of them might have MS Outlook as their model so they have to design their product using Outlook as the model, another might have BBC, and another might be a computer game. This allows them to look at the user journey in a different way but with the same objective.
The attendees found the session enlightening as it gave them an insight into the use cases and what is was about their product was really important. This led to the idea of a product portal and the design of a new generic front-end.
| There is an increasing emphasis on a user-centric design approach and the part the end-user plays in the design process. When I have worked on projects for the Public Sector we often have the Government Digital Services (GDS) guidelines as a requirement. The main focus of these guidelines is the inclusion of the user as the key factor in the design and testing of the product. My view is that the end-user has to be a key stakeholder and should be included but there needs to be a regimented approach to their input. I like to liaise with them during the initial information gathering, then setup milestones throughout the project lifecycle where we can have review sessions when we have something tangible to show them, and the feedback we get can be used to make positive, considered updates. |  |
|
The evalution phase must come at a stage when there is something that is sufficiently rendered to actually review. This may be when:
Conducting a user evaluationThe way that we conduct an evaluation depends on the type of information we want to collect. In a review of a prototype or the user journey this would generally be carried out by walking through each part of the process with the user group, asking questions and recording their feedback with a view to a more in depth evalution when the product was built. My approach to a user evaluation when it comes to a working system is based on the processes I learnt when I did a Postgraduate Degree in User Interface Design and Evaluation. This covered many evaluation techniques but the one that I generally used (as it fed into the type of applications I was reviewing) was a 'discovery - task - question' process. This involved the hosting of a session in which a group of users attend a session based in our offices as this allows for a more controlled environment with less distractions. A session would go like this:
|
|
The cartoon below illustratates the importance of gathering and documenting the requirements in a format that everyone understands. Each member of the team has a different interpretation of the requirements.
A key phase of every project, big or small, is the analysis phase in which information is gathered to determine the requirements and scope of the project. During this phase key members of the team work together; a Business Analyst may gather the functional requirements, an Architect the infrastructure requirements, a Test Lead the test data and so on. A UX Designer will gather information required for the solution design which will generally include:
- Who is the intended user?
- What environment do they work in?
- What are their expectations of this service?
- If it is an existing product then what problems or issues have they faced and how can it be improved?
- What browsers, devices or other technologies are they using, or likely to use in the future?
Case Study - Visiting end-users of a data analysis tool
Evaluate the use of an existing product with a view to a rebuild
I visited a company in Milton Keynes who received a data feed from us containing financial data on consumers, and developed their own front-end to display it. I sat down with their call center staff and watched as they interacted with their users on the phone. Despite the fact that I was not evaluating one of our own products, it was insightful to see how there user interface was used in the interaction, what information was important and how it was laid out.
The end result of this visit was a new approach to the design of our reports. Historically, we had displayed data in a tabular format but this company had shown the same data in a graph which provided a visual representation of the users ability to pay and how there finances were trending.
|
The diagram on the right indicates the possible non-functional requirements that may need to be captured for a project. Many of the requirements will influence the design, so the analysis phase is very important and can take some time with many parties being involved in the decision making process. Knowing all of this will allow us to set the boundaries of the design. For example, an application designed for a Call Centre may need to be keyboard driven, or a government organisation may have very strict accessibility requirements. It would be nice to have spinny widgets, sliders and a load of funky stuff that would wow the users, but would it make the application more usable, practical or generate more revenue? |  |
Case Study - Visiting end-users of a data analysis tool
Evaluate the use of an existing product with a view to a rebuild
I visited a company in Milton Keynes who received a data feed from us containing financial data on consumers, and developed their own front-end to display it. I sat down with their call center staff and watched as they interacted with their users on the phone. Despite the fact that I was not evaluating one of our own products, it was insightful to see how there user interface was used in the interaction, what information was important and how it was laid out.
The end result of this visit was a new approach to the design of our reports. Historically, we had displayed data in a tabular format but this company had shown the same data in a graph which provided a visual representation of the users ability to pay and how there finances were trending.
|
For me, the User Journey is the key to the solution. As the name suggests, the User Journey is the route that a user takes through the system. At different points within the journey they will go down different paths, whether by force or by decision. By plotting the route we can break the journey into smaller chunks, then analyse each chunk. Seems complicated but its actually quite simple. I have a method of documentation that I use which work well and can be used face to face with users, clients or as a tool to define the end to end process. Obviously, most clients will want everything and there will be very few 'nice to haves'. It is important to document all of their requirements at the beginning irrespective of whether they are likely to be included, or even whether they are physically possible to achieve. Better to start with a full catalogue then discard requirements as you progress. It also means that you can factor future functionality into the design even though it might not be required initially. There are a number people who collectively provide this information and it can be gathered in several ways. A workshop is a good idea at the start of the project as it helps to get to know each other and chat about the high level requirements and objectives informally. It helps to root out the real 'must haves' and weed out the 'nice to haves'. If the project is based on enhancing an existing product then visiting the user and watching them at work is always useful and helps you to define what 'fit for purpose' means. The UX Designer would ask the user several questions (based on the ones listed above) then watch what they do and make notes. More about this in the UX Evaluation section. Gathering the user journeyThe form on thr right is a form I designed to collect the initial requirements. As you can see the name of the project and the objective of this process is specified at the top then the group discusses what steps need to be taken to achieve that goal. These are listed in the 'User must' column and the way in which this task is measured is entered in the next column. One of the advantages I have found using this process is the ease that you can build up a level of granularity very quickly. The example below shows a breakdown of the tasks in the example above. So you can build up a series of these requirements sheets for all of the tasks and even employ a naming convention such as 1., 1.1, 1.1.1 and so on that can be followed into the next stage of the project. |
  |
It is important that the requirements are not only documented accurately and compehensively but provided in a way that the:
- Product Owners and Stakeholders can identify the scope,
- Development team can identify the functionality,
- Test team can identify the use cases,
- UX team can identify the user interaction
It is imperitive that the UX Designer is aware of not only each task undertaken by the user but all of the different outcomes within the task. For example, something as simple as supplying a name has many variables. We all assume that the name will be entered in a field, but it doesn't have to be (which is why the functional requirements should never specify a solution, just that a mechanism is required to do something). So what happens if the user submits their details without entering the name, or what happens if the format entered is incorrect or the name cannot be found. Solutions for all of these scenarios must be defined before this task can be signed off.
Below is an example of a table I would create that lists the primary requirements and breaks them down into snippets of interaction (tasks). As you can see tasks (which relate back to the requirements gathering diagrams I described earlier), the Acceptance Criteria which lists the key attributes that are needed to complete the task. This criteria is important as it defines a series of use cases that need to be completed in order for the requirement to be marked as 'Complete'.
| Reference | Task/Requirement | Actor | Acceptance Criteria | Notes |
|---|---|---|---|---|
| 001 | User can enter name | User | 001-1 Name must include Title, Forename and Surname 001-2 Title must be selected from a predefined list 001-3 Forename and Surname are mandatory 001-4 User must be informed if invalid characters are input |
Refer to FS for details on field attributes | 002 | User can specify date of birth | User | 002-1 DOB must be in DD/MM/YYCC format 002-2 DOB is mandatory 002-3 A date picker must also be included 002-4 User cannot enter a date <100 years ago 002-5 User cannot enter a date >today |
Refer to FS for details on field attributes | 003 | User can submit the name and date of birth | User | 003-1 An indication is provided when data is submitted 003-2 Submit option must be clearly labelled 003-3 Submit option can be accessed using mouse, keyboard and touch |
When Submit is selected the system must validate the input and verify that the data exists. | 004 | Database checks the data | System | 004-1 System returns data if customer is found 004-2 System returns Not Found message if customer is not found 003-3 System returns error if data is incorrect |
Documentation Types
When you are creating a screened application, the user journey is argueably the most important document that is produced. It describes the end to end process of the solution design, showing each screens, every screen state and all of the use cases. It is important that every scenario is documented as the design is based around the known limitations of the system. The UJD is also very useful to get signoff on the design as it provides a visual representation of the solution and is presented in a user-centric format.
The docs below are typical examples of UJD's and describe each process in clear, non-technical manner.
Example UJD - Statutory Report Example UJD - ConsumerA Design Guide is a high level document that is generally not project specific, used within a department to define a group of products or a set of generic processes. For example, a Design Guide may describe the structure of the site, the elements that would generally go on a search page, or the attributes of each table on a site.
Guess what, a screen specification specifies the screens. Unlike the User Journey which focuses on the usability, a screen specification is a bit more technical as it is used alongside a Design Guide to buid the solution. It contains information about each screen such as a description of the interaction, but also the definition of the on-screen elements; size and shape of buttons, hex values of colours, customised CSS styles that will be needed, etc.
In many organisations, a Functional Specification (FSD) is prepared by a Business Analyst. This describes all of the requirements and functonality that is needed in the final solution. In smaller companies, or projects where the screen design is a key requirement then the UX Designer may write this doc. I have written many FSD's over the years and am familiar with the prepartion and content.
When I have a solution that the client, the business and the project team are happy with then I need to document it. At this point I will probably have a load of documentation that was created during the analysis, and a prototype that was used to demonstrate the final design. Now its a case of putting it all together in a format that can be used by the team to build, test and support the solution I have designed.
The level of documentation may vary depending on the complexity of the design, the level of user interaction, and the detail required by the developers and testers. You may need to decide whether to include the user interaction as an addendum in the Functional Specification (FSD), as a Screen Specification (SSD), or as a User Journey (UJD). As a rule I would always go for a User Journey document. In the past I have created Screen Specifications but have found that the developers will recreate exactly what you have put in front of them without referring to the FSD or other specs. It is better to provide a set of guidelines that define the way the user interacts with the system, and not a guide to what each screen looks like to the last pixel.
The documentation of the requirements in many organisations is the primary responsibility of the Business Analyst. However, there is some documentation that is required from other members of a project team, including the UX Designer, to support the FS. At this stage the requirements are fairly high level but it is important that they are structured in such a way as a single process can provide sufficient information for all of the teams.
When you are specifying the user journey there is a large amount of key information that needs to be included:
- What is the objective of the product?
- What technology does it support?
- How does the application react and adapt to its environment?
- How will the user navigate through the process?
- How are errors handled?
- What business rules are activated in each scenario?
- What help is required?
There are loads of other things to include and, as you can imagine, it is a comprehensive guide to the solution. Perhaps the best way to describe these docs is to show you a couple of examples that you can take a look at. You wil see that the format of the document remains the same in each case but the information and level of detail changes according to the complexity of the solution.
Gathering UX Requirements
There are a number people who collectively provide this information and it can be gathered in several ways. A workshop is a good idea at the start of the project as it helps to get to know each other and chat about the high level requirements and objectives informally. It helps to root out the real 'must haves' and weed out the 'nice to haves'. If the project is based on enhancing an existing product then visiting the user and watching them at work is always useful and helps you to define what 'fit for purpose' means. The UX Designer would ask the user several questions (based on the ones listed above) then watch what they do and make notes. More about this in the UX Evaluation section.
Gathering the user journey
The form below is a typical example of a form I would use to collect the initial requirements. As you can see the name of the project and the objective of this process is specified at the top then the group discusses what steps need to be taken to achieve that goal. These are listed in the 'User must' column and the way in which this task is measured is entered in the next column.
One of the advantages I have found using this process is the ease that you can build up a level of granularity very quickly. The example below shows a breakdown of the tasks in the example above. So you can build up a series of these requirements sheets for all of the tasks and even employ a naming convention such as 1., 1.1, 1.1.1 and so on that can be followed into the next stage of the project.