First I identify the requirements from initial meetings, a design brief, emails and documentation > then research is gathered for me and/or I carry out a discovery phase myself > then I create use cases based on those requirements > from those, build task flows > from that, start sketching and create a clickable/shareable wireframe to validate > from that, comes the prototype which I'd either create in Sketch or code in HTML and CSS using a front-end framework like Bootstrap (talk to the lead developer first so they can tell you how they'd like you to code, enabling them to use your code in production) > then feedback from stakeholders. If you have the resources you can carry out user testing with clients and other UX researchers.
Team members rely on me for information and direction. The teams I usually work with are made up of product managers, various developers, dev analysts and business analysts. I work to build strong relationships with everyone on the team as I don’t approach projects in a dictatorship kind of way but at the same time lead when I need to. I like to constantly communicate and converse with team members (big part of the design process). When everyone is working well together that is when the good work is turned around quickly. See below for details of how I fit into an Agile team.
At EYC, one of the product managers (I was working with 7 different teams) wanted to use a wizard built by developers in India instead of using the forms we had designed in Richmond. To solve this I created a prototype of the forms we had designed and explained in an email to my manager and both teams why our forms were more efficient by walking them through the use cases, including those they hadn’t considered. I’m objective and back up claims but always aim to disprove, or for others to disprove, my claims. That’s what I believe makes me reliable from a stakeholder's POV.
At EYC, I designed many bespoke components, one which analysts liked was the in-chart time select slider which allowed users to select an event and comparison from within the chart. Prior to this users needed to go to a menu or filters panel located elsewhere on the page. With the new design they can see the bit of data they want to select and can select it straight away. This also reduced the interaction count. Before I created this, it was really fiddly and time consuming for users to make these selections.
Other than big things like virtual reality, artificial intelligence and quantum computing, I’d say menu-less or near menu-less applications, where the UI is so efficient that there is no need for them anymore. We’ll see this first on native mobile apps, then it will be carried over into the bigger more complex web apps for desktop users. I see this more and more having worked with charts over the last few years, if people want to do something they don’t want to have to go to a menu to do it.
First I check if any has been done before (at EYC a BA had done some great research that was nearly forgotten about). Then I carry out a discovery phase myself which should consist of: (1) Workshops - minimum 5 people but 18 is my ideal amount as this means I can do three 6-people workshops. These are great for getting a lot of reliable information in one go; (2) Surveys - an unlimited amount of people can take them for you, but less reliable with no guarantee when or if you will get them back; (3) Interviews - the most common method as this can be done with anyone, anywhere at any time.
At the beginning of a contract, one of my priorities is to try and find out the names of: (1) People who 'Make' - the people who will have to actually make the product - engineers; (2) People who 'Buy' - where is the money going to come from/who will buy the product? Who are the people who are investing in this product and why are they investing in it?; (3) People who 'Use' - people who will use the product after we've made and sold it; (4) People who 'Know' - people who know about the product, competition and industry - client teams, sales teams, BAs etc. If you can resolve the arguments between these four sets of people then you will have a good product.
After the wireframing and prototype phase which is normally done with the stakeholders, the prototype can be tested with users. Tools for testing are: (1) VWO - industry standard for optimising websites and web apps; (2) Inspectlet - simply records users' screen activity; (3) Optimizely - create variations from within the app and multivariate test; (4) Usabilla - users can give live feedback on things they like and don’t like; (5) Usabilityhub - five second test, question test, click test, preference test, navigation test; (6) Userzoom - measures all interactions and also records users' screen activity; (7) Crazyegg - heatmaps, page scroll maps, overlays, confetti; (8) Hotjar - heatmaps, visitor recordings, conversion funnels, form analysis, feedback polls, surveys, recruit test users.
Goals for testing include: (1) Destination - a specific location loads e.g. a "Thank you for registering!" web page or app screen; (2) Duration - sessions that lasts a specific amount of time or longer e.g. 10 minutes or longer spent on a support site; (3) Pages/Screens per session - a user views a specific number of pages or screens e.g. 5 pages or screens have been loaded (4); Event - an action defined as an Event is triggered e.g. social media recommendation, video play, ad click.
Metrics to measure include: (1) Happiness (via a survey) - satisfaction, perceived ease of use, net-promoter score; (2) Engagement - number of visits per user per week, number of photos uploaded per user per week, number of shares; (3) Adoption - upgrades to the latest version, new subscriptions created, purchases made by new users; (4) Retention - number of active users remaining present over time, renewal rate or failure to retain (churn), repeat purchases; (5) Task success - search result success, time to upload a photo, profile creation complete.
Post-test survey tools would include: (1) UsabilityHub - 'New Question Test'; (2) SurveyMonkey; (3) Google Forms. Questions could include e.g. for a form A/B test: (Q1) Which variation was the quickest to complete - ‘form-page-a.html’ or ‘form-page-b.html’?; (Q2) Which variation was easiest for you to review your previously completed steps?; (Q3) Were you sure that when you clicked SAVE, that all your data was saved or just the tab you were on?
I've used Mockingbird for quicker wireframes because it's super easy to use and share which is great for collaboration purposes, and means after I leave a contract the teams can still modify, share and export the wireframe. Or Sketch because it's the best product for high-fidelity work.
Both. PC's can do everything a Mac can do apart from recently with Apple's Sketch app which will only work on a Mac as the app needs both Apple's software and hardware to work. Until Sketch, it's been the other way round. Since Sketch there has been a lot more design resources available created by Sketch users that I can't benefit from as a PC user, so I now mainly use a Macbook Pro.
If they only had different design languages then I’d show them to the team and clients to see what people preferred. If it’s something less subjective then I’d prefer to make three wireframes or low fidelity prototypes to test which one is the best. Changing the UI once it's been implemented is not as quick to do as people think and can be costly. Making sure the correct UI is used at the beginning is worth spending this relatively (relative to how long it will take a team to change the UI) small amount of time on.
Context of use would be: (1) Identify - who the primary users of the product are, why they will use the product, what their requirements are and under what environment they will use it; (2) Specify Requirements - once the context is specified, it is the time to identify the granular requirements of the product. This is an important process which can further facilitate the designers to create storyboards, and set important goals to make the product successful; (3) Create Design Solutions and Development - based on product goals and requirements, start an iterative process of product design and development; (4) Evaluate Product - usability testing to get users' feedback of the product. Product evaluation is a crucial step in product development which gives critical feedback of the product.
A software product is 'done' when there are no more bugs to fix, and all requirements have been implemented correctly (which is rare).
Provide evidence to back up my claim including test results and the opinion of others in the team or company, remaining objective and always open to being proven wrong. And always put the company's interests first.
While working as an automotive technician for Jaguar I had it drummed into me at a young age the importance of doing a job to a high standard quickly. Following that, my experience with car design taught me a lot about product design and the design process, as car makers are people who get it right and get it right first time without a need for a second release or bug fixes. These are physical products that are expensive to buy, sell in high volume, are well known in the public domain and are still turned around very quickly. Companies I work with can take advantage of some of the processes and philosophies used when car makers make a car.
I always try to remain objective, and where possible I will provide evidence or a reason why a decision has been made. I am always open to new information and suggestions from anyone and like to be challenged. Because of this I think the teams I work with usually trust me to lead the product on successfully.
Core things I’d look for would be; (1) Usability - ease of use, do I know where everything is; (2) Functionality - interaction design, speed; (3) Content - what information or service does this provide.
At EYC, my manager wanted to go with a top navigation layout and I wanted to go with a side navigation layout on quite a big application. So I created an email detailing why the side navigation is so much more extensible and efficient under all use cases, including the unknown navigation options there might be and how they might appear on different devices and view port sizes. After that email he decided to go with my suggestion.
Constantly. I sketch while I am explaining things to people, I sketch while I am in meetings, I sketch while I am working, I sketch and add photos of those sketches to Jira/TFS or similar which really helps developers, I sketch when I think, and sketch wireframes before I create the final clickable web-based wireframe to share.
Users generally prefer designs that are fast and easy to use (70% of the time), but satisfaction isn't 100% correlated with objective usability metrics. These metrics would include: satisfaction, perceived ease of use, net-promoter score (willingness of customers to recommend a company's products) all collected via a survey.
An organisation needs to get its segmentation right before building personas around them. Personas are a single fictional character within a segment, the segment is the group the persona fits within.
Personas are a useful tool to visualize the target audience, and they are very helpful in creating user stories during the design phases of your product. They remain fictional however, and are not reality. One of their great weaknesses is for people involved in the design process to take them too literally. To prevent this it is useful to keep them as abstract as possible, just like a wireframe should be an abstract (absent of design language) and not a finished product. Another disadvantage is that they can sometimes stand in the way of thinking how you would use a product yourself - they can actually prevent empathy. When you fail to identify with your audience, chances are you think up rules of behaviour which you normally would not want to be the subject of yourself.
I approach digital products the same way I approach physical products. I make sure I organise myself at the beginning to make sure I can get it right first time preventing very expensive, difficult and risky change later on in the product life cycle.
Which one would you pay for to use every day, and why?
I push the 'risk' button and highlight how a usability test would help mitigate that risk. I've communicated usability issues to the rest of the team and received a push back from the product owners, decision-maker in management and even from developers. Their rationale is that other big companies already use it and since it’s good enough for them then it must be good enough for us.
I just aim to increase the chance of having a successful product launch by making sure our users can easily complete the main tasks in the product. We could go straight to launch with the risk of upsetting some users and as a result lose customers and get bad reviews, or we could quickly test what we have and find out at the beginning to avoid any expensive mistakes at the end. Highlight the risk of losing customers, which would make product owners look bad and in the end let them retain the decision-making right. I don't threaten to block the launch and acknowledged their right to go straight to launching the product without any usability test.
Yes, at EYC a lot of user research had already been carried out by the BA so this fed straight into the product when we began working on it nearly a year later, all the research was still relevant and true. I fed this back into the design of the product.
Yes, Agile project management is something most software teams try to use and all companies I've worked with have been Agile at some stage.
I do this by: (1) Carrying out work in a 'black ops' missionary kind of way, not as a dictator - spending more time facilitating UX work by the whole team reduces ongoing problems and frees up the time to focus on the harder UX issues; (2) I'll embedded within the team - the Agile approach of incremental delivery needs continual design input, and separate design groups can’t do this as well as when they're within the team; (3) Adapting my deliverables - when you’re working with the rest of the team, you can answer their questions directly rather than writing a style guide (although style guides can be very helpful if you have them already or have the time to do them). You can address the problems from a usability test immediately rather than writing a report. Less time authoring unnecessary documentation means more time for you to help make a product great; (4) Pitching in - by getting more involved with tasks outside my immediate area of expertise, like development, product management and QA, I find new ways to apply UX knowledge and help make a product even better.
Usually when product owners want a feature, said feature needs to be both designed from a UX POV and implemented in a UI POV for the devs to build out during that sprint. This works 90% of the time as long as the designer has a plan and/or scope of the product at large. The two most popular ways software companies work are: (1) UX work only happens during the sprint in a very ad-hoc, collaborative way; (2) a small tight-knit dev team with a UX/UI designer works ahead a few sprints to get things prepped for the main team allowing them to build faster and more accurately. This second method closely follows a methodology architects use in the construction industry called ALDB (Architect-Lead Design-Build). Like Agile this process is about collaboration and constant iteration which also allows the designers to fully exercise the design process, eliminating the pain points you see with method 1. If companies don't have the resources for two teams then my time will be split between method 1 and method 2.
I once designed and built an app with a small team I managed in 10 days. At EYC we needed to create a web app that used real data, the data was ready as a dev analyst and myself had already created an Excel product that used the data we needed. We had 10 working days to turn that Excel product into a desktop web app that could also be demoed on an iPhone and iPad. We completed the work on the tenth day and I was responsible for running the team which consisted of the dev analyst, one back end dev, one front end dev and an external consultant.
Good UX is about predictability i.e. if a user takes X action do they know that Y is going to happen. You need to ensure that the design patterns and user journeys are extensible and appear the same on different devices and view port sizes. Also always try and take things away, Leonardo Di Vinci said "a poet knows when he has reached true perfection, not when there is nothing left to add, but when there is nothing left to take away".
I spent a few years working in e-commerce where I carried out A/B testing (using Google Analytics) to create more profitable sales and landing pages. Those tests were a lot of fun.
As a designer I have to speak to a lot of people, so relationship management is a big part of my job. Good rapport with stakeholders and the team you are working with is an essential part of the design process.
Designing a product is more than making things just look good and making sure they work well. You need: (1) Good planning - design is effectively the practice of good planning, see UCD; (2) Good coordination - describes the successful integration of designs prepared by different members of the project team to create a single, unified set of information that can be constructed without clashes between components. Effective design coordination can help to reduce costs, delays and disruption; (3) Good communication - whether with users, clients, or other team members, UX professionals need to calibrate a combination of words, wireframes and documents to different people with the right positive attitude and without using any terms that people won’t understand. It's also always important to remember this always takes place in a social setting (design is a social science). Before I got my first job, I contacted someone who owned a web design agency in Swansea who told me "I would rather take someone on with less experience who had the right attitude than someone with more experience who didn't". Without good communication, good design rarely happens.
To validate ideas and resolve complex arguments. With a smile.View work chevron_right
copyright © Richard Heale