Classical music has always inspired me, and I’ve often found it an excellent inspiration and accompaniment to my work. It was because of this that I put together a dark classical playlist named Miserichordia, which I’ve cultivated over time to include requiems, fugues and atmospherics from famous composers and film scores, to evoke that exquisite darkness found in classical music. Use it to help with your work, your reading, or even as something to inspire your own dark musings.
SkyNet isn’t the problem: How UX and AI can work together
Introduction
The recent rise in articles and opinion pieces around AI has led to some pretty odd claims, either saying that AI is here to take our jobs as UX designers, or even more dangerously, suggesting that AI can be used in place of proper user research. In this piece, I detail a discussion I had with another UX thought leader about ways in which we envisage AI could help UX designers, including:
In my previous post, I stated that a number of large companies fail to follow user-centred production processes, and that by adhering to those processes, you can get ahead of a lot of the competition. As a way of providing more detail to my claims, I’m sharing a talk I previously gave on this very subject, how I discovered that it was enough of a common phenomenon that it actually had a name, how it affects more than just designers, and how everyone on a software production team can work to address it.
The user-centred production process
Everyone who has worked in a project team to produce something should be aware of the User Centred Production process, (also known as User Centred Design, but I prefer to call it a production process, so that it’s more inclusive to non-designers). It’s a valuable mechanism which ensures, by identifying and placing user needs at the centre of production decisions, the resulting product will be successful with users because it addresses those needs. This is a fundamental improvement on previous production methods, which would try and guess what users wanted, build and launch something to address that, and then adjust the product in the next version, or build something else, which could be very time consuming and costly.
Discovery – a collaborative exercise to define the aims and scope of the project, giving a rough idea of what is being achieved, and how it will be achieved
Research – conducting research with people who actually will or currently use the product, to gain insights around their requirements, and ensure that what you plan to build addresses their needs
Analysis – reviewing what’s discovered during research, highlighting opportunities and problems, identifying user types and their interactions, and noting further questions and assumptions for further research
Prototyping – quickly creating low fidelity solutions, doing just enough to be able to challenge assumptions and questions, and start a process of slowly improving fidelity as understanding grows, aiming towards a finished product.
User testing – letting users try the prototype, testing assumptions, asking questions, and providing feedback for further development as part of a “build, measure, learn” cycle.
Launch – the product can now reach a “minimum viable product” level where it’s ready to ship, and can be widely released. The “build, measure, learn” process can continue, for further refinement and to address further issues.
So why do companies get this wrong?
As previously mentioned, I’ve worked with a number of companies who fail to follow this process, and there are various reasons why this happens. I’ve included them below, with some actual quotes from project leads, justifying why they’re not following the process properly:
Lack of appreciation of the value of the process
“I’ve been in this industry for 15 years, I know what users want, so we don’t need to waste time on research.”
“We don’t need to conduct research, let’s just build something and test it.”
Project leads in this example assume that they don’t need research, and that they can save time and effort by not including it in the production process. This may well be down to a lack of experience of how good research can inform a project. I’ve always found during research that not only does it identify basic needs, which the people above may well be aware of, but there is always something which you didn’t expect – a new discovery, an added benefit, or a “gotcha” moment that changes your perspective. These are impossible to predict, and understanding them can mean the difference between a functional product and a truly great product. Also, in the second quote, by not conducting research before you start building something, you run the risk of building entirely the wrong thing, and wasting time and effort by having to revise it heavily, or scrap it altogether. Research before production ensures that you have a decent understanding of user needs, and have identified opportunities and problems before you begin.
Lack of interest in engaging with users
“We don’t really have connections with our customers, so it’s going to be hard getting people to talk to.”
“Our users are far too busy to engage in research.”
“We would get you some users to talk to, but Sales are far too busy.”
Project teams are often distanced from Sales and Customer Relations in larger companies, and this can sometimes be used as apathy to not engage in user research. I actually heard the first quote while working on a scientific database product, and I detail in my case study about how I had to go out myself and find research candidates, because the project leads were unable to. This friction is usually the cause of project leads being unable to provide links, or scared that if they do, the research will harm sales in some way. A lot of my experience runs counter to this, and having users take part in research, they feel invested in the process and that their requirements are being individually addressed. This can actually help with Sales efforts, and gain useful knowledge that will be beneficial to them.
Time constraints
“I’ve promised that we’ll deliver this product in (x) weeks. We haven’t got time to research or test with users.”
Project leaders stating they haven’t enough time for research indicate more lack of appreciation of the benefits of research. They may not have given time to conduct research because of an adherence to antiquated production techniques that aren’t user centred, or they don’t include time for research because they don’t see its value. Projects should always include time to conduct research as a fundamental part of the user-centred production process, and the concept that research takes a lot of time can be quelled by drawing up research schedules to demonstrate that they fit in the overall project roadmap. Ideally, Agile projects should include continual research, which allows some degree of running research alongside production, although this could introduce the need for some rapid changes of direction if new discoveries are made.
Pressure to deliver
“We can’t pause production to conduct research, we’ve got to start building something immediately!”
It’s understandable that projects have deadlines, as value and progress need to be demonstrated, but the need to build something quickly indicates again that time has not been allocated for research properly. Research should be an important part of initial project planning, and the understanding of its value and the need for allocating time should be made clear to all participants and stakeholders from the start. By doing this, you will ensure that stakeholders will ask to see research discoveries, rather than product progress.
Discovering UX Theatre
After seeing these patterns, I came across a number of articles which indicated that I wasn’t alone in this situation:
A series of headlines from online articles stating that there’s a fundamental problem with how UX is being practiced in some companies.
These articles led me to the discovery that this term “UX Theatre” had been coined by Tanya Snook in 2018, describing it as:
“the application of any sort of design methodology without including a single user in the process, or including users but merely for show.”
As we’ve previously discussed, missing out on research means that you could start building the wrong thing, but what if you missed out on other parts of the process?
Missing out on analysis (which often happens if you don’t research, as there’s nothing to analyse) means that you fail to identify opportunities and problems before you start building solutions.
Missing out on prototyping means that you don’t iterate on your design, and the user doesn’t see it before launch.
Missing out on testing (which happens if you don’t prototype) means that you increase the risk of the product failing upon launch
This last point is best described in a diagram I saw in a talk by Josh Sieden, co-author of the excellent Lean UX: Designing Great Products with Agile Teams, which has been a fundamental part of my UX learning. In the last slide of his talk, he included this diagram, which describes how continual iterative testing minimises risk in a product production process:
A graph showing how continual production without testing increases risk (red line), whereas each instance of testing reduces the risk back to zero each time (blue line).
This helps explain the value of iterative testing (a subject I’ve written about before), and how it’s an important part of the user-centred production process, a process which, as indicated above, should be followed fully.
So, what can we do to address this?
The responsibility to identify and address UX Theatre doesn’t just stand with designers, as, demonstrated above, it affects the whole production process and the team. It is here that I invoke one of my favourite film quotes, the inimitable Jeff Goldblum playing Dr Ian Malcolm in Jurassic Park:
Everyone in a production team should be able to challenge the way in which a project is being conducted, and ask for more information about how decisions are being made. To that end, here are some things you can ask:
Check with your team that they’re building the right thing (research)
Have they provided research and analysis documentation and thinking, to justify their production decisions? Are they based on conversations with actual users, or just assumed?
Did they write their “as a user…” statements based upon actual research discoveries, or are they just making them up out of what they think is right?
What other assumptions are being made?
Check with your team that you’re building the thing right (testing)
Is the project following an iterative “build, measure, learn” process, building a Minimum Viable Product, just high enough fidelity to test, and then rebuild based upon the discoveries made while testing?
Or are they building a Minimum Sellable Product, which won’t be tested with users until it is launched?
If you can, make sure the project is properly structured
If you’re part of the initial planning of a project, ensure that the structure of the project includes each of the stages of the user-centred production process above.
If people question why these sections should be included, provide examples of ways that each stage is useful, and explanations of what could happen if they are omitted.
Conclusion
By identifying and preventing UX Theatre being practised, you’re achieving a number of things:
Preventing wasting production time and expense by working in an iterative method, being able to identify problems and address them proactively
Creating products that are more successful, and not only address the needs of users, but also identify ways in which to delight them.
Reducing frustration in project teams, providing more opportunities for them to learn about users (which can prove useful in future projects), and making products which demonstrate success that they can proud of.
Thank you for reading this through, and for helping to make products and project better!
If you’d like me to help with ensuring success in your products and teams, please get in touch, and we can discuss your needs.
Years ago, when I started out in UX design, I thought that the experts in my field had all this arcane knowledge around UX, knowing all these tricks about how to handle projects and how to make products the very best that they can be.
You know what over a decade working in UX has taught me?
Listening to your customers;
Understanding their collective and different needs; and
Ensuring that what you’re making addresses those needs;
is enough to put you ahead of most of your competitors.
This simple premise is one that everyone in a company should be aware of, and yet I’ve witnessed a number of large influential companies out there who still don’t manage it. If you’d like me to help your company, let’s talk.
Building a strategy to demonstrate proactive design value
Introduction
Starting as Head of Design at a relatively young commodities trading company, I quickly identified a common pattern that I had seen in previous roles – namely that the Design department currently existed as a reactive entity, addressing requests from development teams, management and other departments, leading to a focus on UI design work for production. I made a more proactive Design approach my objective, so that we could help provide research insights to help inform strategic decisions, and provide design value in a more holistic manner to ensure visual and functional unity across all of our properties.
Communication
To get this approach started, communication would be key – the company already had different teams spread across three offices, as well as teams working in a siloed manner, often unaware of efforts made by their colleagues. To start, I advocated for a single unified Confluence wiki for all the technology teams, and ensured that everyone involved with those teams, from the most junior developers to the CEO, were able to access the pages on the wiki. This resource would become a central repository which would record all our efforts, from initial ideas through to final releases, and provide a way for anyone in the company to come and review our work.
Diagram showing how collecting research intelligence and analysis can help inform both project level and company level strategy
It was here that I was able to define the structure of my plan above, and share it with C-level executives and other department heads. This came a regular weekly update, where I could provide an email, summarising our work and progress, and providing links back to the wiki for more information, not only keeping everyone updated, but also inviting opportunities for collaboration, and making use of more people’s skillsets.
Hiring
Previously, the Design discipline had primarily been part of the team working on improving the current design platform, and so it was important to maintain this support while also being able to expand out the Design offering. To get started, we arranged to hire an experienced contract User Interface designer, so that they could start supporting the production teams as soon as possible.
I wanted to ensure a fair hiring process, and so developed a job specification which was based around Lou Adler’s Performance Based Hiring method. Instead of a creating a “laundry list” of skills and requirements which can be intimidating to some demographics, I created a set of expectations for the role, based around what they would be going in three, six and twelve months, which not only helped them to apply their varied experiences to the role, but also gave better vision of how the role would evolve from UI support for a current project, to being involved in wire framing for future concept projects. I’m proud to say that, using this approach, we managed to encourage a more diverse set of candidates, and have a better range of choice for the role.
Research
Having secured UI support, I was then able to devote resources towards research. It was my aim to establish continual “rolling” research, so that interviews were being conducted with a regular cadence, providing continual insights as well as a resource to quickly get answers to any new questions which arose during production work.
To start, interviews were set up with internal colleagues who made use of the trading platform, to better understand how they used it (providing insights into improvements) and also examining their work practices (understanding how the platform currently fitted into their work, and identifying opportunities for other ways in which we could improve their situation). These interviews were recorded, so that we could then listen back and draw out observations, which then acted as a central repository of insights to build analysis from, identifying trends between responses from different people, or different use cases for each. These insights not only helped to build a picture of needs for current and future versions of the platform, but also a wider picture of the way in which the needs of our users affected the direction for different products in the company.
Analysis
Taking the feedback, I was able to put together a journey map for each type of user, which allowed me to examine their interactions, flag up problems and opportunities, and highlight questions that arose from those discoveries.
A user journey for a single user type, showing their actions before, during and after they use the software, and including possible issues indicated in red and opportunities indicated in green
These journey maps could then be combined to get a wider picture of the whole ecosystem, and understand the touchpoints where users interacted with the products, and well as their requirements when they weren’t using the software.
Combined user journeys, understanding the wider ecosystem of how different user types interact with each other, as well as the software
Some of the insights I collected included:
Simplifying the user interface: previous versions of the platform had presented fill details to the user of all the different commodities and markets. It was clear from the research that the majority of users were only interested in one commodity, or specific markets, and they found it useful to show and hide information which wasn’t relevant to them.
Combining interfaces: users found that the various products offered by the company, alongside other information sources, led to a confusing number of tabs to keep track of. This verified a business requirement to combine the trading and research products, as well as considering how other information sources could be integrated.
An idea to combine previously separate services into a single information service that users can customise to focus on the one or more markets that they are interested in, which a variety of touchpoints for them to access information.
Ideation
I was able to share these discoveries with management and colleagues in a series of ideation sessions, which not only helped inform them about my discoveries and progress, but through a series of activities, we were able to make use of the skills and expertise of everyone involved to devise ideas and plan ways to address identified problems and develop new initiatives. These included:
Architectural mapping with stakeholders: reviewing current informationarchitectures, identifying experience rot and obsolete features, and comparing user journeys to help product more intuitive structures which fitted with user expectations and requirements.[image of revised information architectures]
Turning complex website structures……into fewer pages and less complexity, improving navigation
Competitor review: investigating competitor products and presences to understand the wider market, identify gaps, understand where we can and cannot provide a unique value.
Discussion and ideation: we were able to present findings to C-level executives and then discuss the impact these discoveries would have upon future company strategy and product plans.
Conclusion
These approaches generated some very good ideas for the future of the company and it products, and I feel that they would have certainly helped lift the company’s offering above that of its competitors. Sadly, the company decided that they wanted to follow a different direction. I would be very keen to evolve this approach and develop it for use in other companies, so that it can be brought to properly benefit them instead. If you are interested in this approach, and would like to apply it at your company, please let me know!
I recently came across Katie Jacquez’s highly useful post I’m a designer at LinkedIn, here are 4 tips to attract recruiter with your profile. This post provides a valuable insight into how recruiters search for profiles, and how you can tune your profile to work for you, merely by adjusting the Headline, About and Skills sections. I’ve been constantly frustrated in the past with the number of recruiters on LinkedIn who approach me, asking if I’m interested in roles which have little to do with my skillset, and I’ve previously put it down to their use of keywords to find me, and their inability to actually bother to actually read my profile. Turns out that yes, recruiters are time-poor and do resort to finding people using keywords, but you can control those keywords and messaging to ensure that you get more useful offers.
I’d previously worked with my Headline and About sections, but Katie’s piece helped me to even focus further on the initial messages I wanted to convey to recruiters who only had time to scan those sections. The real power, however, comes in the Skills section, as this acts as the central resource for keywords by which recruiters search for viable candidates for their roles. I had previously passed it off as not very useful, and had filled it with various things I was good at, as well as some things which I was passable at, but I felt helped pad out my experience. It was only after reading the post that I realised that perhaps the reason why I had recruiters coming to me with development jobs in Python or C++ was because I had some time ago stated I knew a bit of JavaScript (a mistake, as I’m still not terribly good at it), which caused the recruiters to assume that I was interested in working with other languages. What’s more, looking at the order of the skills on my list, I realised that I didn’t have the ones I wanted to show off the most at the top, and there wasn’t really an order of preference. No wonder I kept on getting confused recruiters, asking if I had experience in conducting user research, when that was languishing lower down my list!
By making these simple changes, I managed to greatly improve the quality of responses from recruiters, with one of them even yesterday complementing me on how comprehensive and useful she found my profile. Of course, there are still those who don’t bother to consider my level of experience and offer me junior design roles, or care to read the first line of my About section that states I only add people I’ve worked with, but at least I haven’t been offered another coding job since I made the changes.
Sharing the benefits of UX with colleagues and clients
Summary
I‘ve worked with a number of companies in my time, all with differing levels of UX maturity. In this case study, I’ll share some of the ways in which I’ve advocated for better awareness of UX practices, and provide ideas around how you can share them with yours.
Introduction
When you join a new company as a UX Designer, one of the first things to understand is the level of UX maturity within that company. Are they carrying out end-to-end full UX processes in their projects, involving non-UX colleagues in their processes, or are they confused between UX and UI, and end up with meetings full of designers pushing pixels while product owners dictating how the product should work, without a user in sight?
The introductory “What is UX” presentation
In many cases, you will have to introduce yourself to your colleagues, as well as set out your stall as a UX practitioner within the company. One popular way of doing this is the “What is UX” presentation, a deck of slides that help introduce those less familiar to how you’re going to introduce better UX practices, as well as providing details about your team, and your plans over how you’re going to implement your plans, ideally liaising with colleagues outside your team to ensure buy-in from everyone involved. This presentation is often given as a roadshow, giving you a chance to travel to different offices and meet colleagues. What’s more, this often also allows you to identify people who are interested in the processes you are talking about, and might become useful advocates later on.
A typical slide from a “What is UX” presentation, breaking some misconceptions around what some perceive UX to be.
Information sheets
Whilst a presentation might be useful in informing people of your plans, it is also useful to communicate smaller concepts with colleagues and stakeholders during projects. One such method we devised was designing “One Page UX Processes”, a series of one page PDFs which we could use as a tool to help explain a concept to someone, and then leave behind with them to later review, or share with others. We designed the sheets to give a high-level overview, explaining what each concept is, how it works, and the benefits of using it.
An example “One Page Process Sheet”, explaining principles behind Iterative Processing and Lean UX Design
Remote ideation workshop
People often learn better by doing, and, when asked to provide a short workshop during a remote office activity afternoon, I saw the opportunity to provide something that would both educate and entertain. I therefore devised a small ideation workshop, which would help my colleagues to learn about the UX process, as well as having a chance to be creative, think in ways they were not used to thinking, and even introduce a note of competition around the solutions they created.
I worked out a simple open ended problem, asking them to devise a route-finding application, and then created three personas – an old man, a blind woman, and a cycle courier. I introduced the team to the problem and these three personas, and asked them to draw a solution which took the requirements of the three personas into consideration. Of course, I assured those who said that they couldn’t draw that this was conceptual, and they could communicate their ideas using boxes, arrows and wording. I gave them about 20 minutes to draw, and then asked each person to share and explain their ideas with the group, encouraging the rest of the group to ask questions and provide feedback after they had finished. The group said that they found the session highly enjoyable, and felt that they appreciated how UX design was focussed upon user needs, rather than something dreamed up by the production team.
The guide I provided to the remote ideation session, showing how people could draw and share their ideas with the group
Blog posts
UX is a continual learning process, and during my work, I also make interesting discoveries. I was invited to share some thoughts on the company blog, and so again used this as a teaching opportunity. I wanted to share details about the importance of an iterative approach to software production, but felt that just talking about that could be seen as a bit dry. I remembered the story that I had read when I was young of Percy Shaw, who discovered Cats Eyes, the road safety feature that lit up the centre white line of the road by reflecting car headlights back at them. I remembered in the story about how Shaw had iterated numerous times on his design, and had even literally “road tested” his creations on a stretch of country road late at night himself, eventually gaining a contract with the Government to produce them for UK roads, after streetlights were put out to evade bombing runs in World War II. This blog post gained praise from colleagues and clients, and became a useful link to share with people who tried to cut corners when it came to testing the products they were building.
The blog post I wrote on Cats Eyes, and showing the value of iterative design and testing
All of the above initiatives can be useful ways of communicating ideas, but their efficacy is severely diminished without one important element – conversation. This could be discussions of UX processes during a project, a chat with a colleague during a coffee break, or any number of touchpoint interactions where you get the chance to discuss how you can help with a problem. The conversations help glue together other initiatives such as the ones above, and help remind people of their existence, so that when a situation arises which could benefit from these approaches, they turn to UX for help.
As previously mentioned, you can also use these opportunities to work out the people who are more receptive and excited by how these ideas can help. These people can often turn into advocates, who can help you spread the message, and, if they are senior, might even help effect change within company-wide practices.
Conclusion
Hopefully some, or even all, of these ideas will help you share the benefits of User Experience within your own work. If you have any methods that you would like to share, or even if you used some of the ideas above successfully, please let me know!
How and why you should conduct better user research in your projects
Introduction
Having worked on software development projects for a range of different clients and industries, I have frequently seen that user research is conducted poorly, or even not at all. In this piece, I conduct an in-depth analysis of how to conduct successful user research for your project, and why it is so important. This includes:
Guerrilla UX in a pandemic: encouraging best practices in adverse situations
Summary
Working as UX Designers, we can often be put into situations where clients are unaware of the value of UX practices, and we have to not only explain that value, but to also demonstrate it. In this portfolio piece, I describe how I worked remotely on a technically complex project during a pandemic, with no affordance made for discovery and research, how I helped the client understand the value of what I was doing, and worked tactically to demonstrate value beyond their expectations to make an outcome that everyone was proud of.
Introduction
Just before lockdown was announced in March 2020 in the United Kingdom, I had started work with a software consultancy whose clients included some of the more well known financial institutions in the City of London. One such company wanted us to help them update their fixed-income bonds trading software, as it ran on the soon-to-be retired Adobe Flash platform, meaning that their software, through which millions of pounds flowed through every day, would stop working. Alongside this mainly engineering led objective, I was included in the team with the somewhat abstract goal of “improve the design while we fix the platform”.
One of the major challenges that I also faced was the complexity of the system. Fixed income bonds trading can take up to six months to learn to just get started, and I was working with a client who felt that I should be producing designs as soon as possible, as they had only previously worked with User Interface designers, and did not appreciate the value of a proper UX process.
Demonstrating value, while conducting discovery
I therefore needed to be able to demonstrate value quickly, and the easiest way to do this is to ensure that the client is kept regularly appraised of progress, and sees a constant series of artefacts to demonstrate the progression in thinking. I started by persuading the client to grant me access to stakeholders and users, so that I could begin to get a better appreciation of the project context. I started with the stakeholders, who consisted of project members and subject matter experts on the client side. I was able to set up a number of calls with them, for them to explain their perspectives and opinions on the project. This provided a firm foundation from which I could then begin to assemble my own picture of the situation, which I coalesced into a user journey, expressed on a whiteboard. On this whiteboard, I was able to define the definite known parts, assumptions and questions I still had yet to answer.
Mapping out the overall stages and observations around the trading software user journey
This whiteboard became my first “information radiator” – an asset where I could share my thoughts with others on the team, and get their inputs and insights. Usually, a whiteboard like this would be placed somewhere prominent in the workspace, ensuring that people saw it regularly, and inviting people to leave comments and ideas. However, as we were all stuck at home, I had to ensure that it was freely available to everyone on the project in a digital form that could be easily updated, so I carved out my won section of the project Confluence wiki for my UX work, where I began to write up my thoughts, post pictures, and encourage people to check up regularly, leave comments and feedback.
Sharing information in a project using confluence (note: this is a generic screenshot from Atlassian, and not a page from our project confluence)
Conducting dynamic interviews
Using my explorations on the whiteboard, I could then collect the “unknowns”; the questions, assumptions and ideas I had written down, and use them to make a interview guide, which was also shared with my colleagues for feedback. I could then begin to arrange some sessions with actual users, with a list of ready questions to ensure that we filled in as many gaps in my understanding as possible.
For user interviews, I would usually try and meet with the user face to face, discuss their working practices, and examine the ways in which the product would fit with their requirements. However, as this was during the pandemic, and we were all stuck at home, I had to arrange calls with them instead. This situation was useful in some ways, as their isolation meant that they weren’t as distracted as if they were on a busy trading floor. However, they were still working, and our conversations were often interrupted by a steady stream of notification sounds coming from their trading software, with them often having to pause answering my questions to deal with a new trading ticket that had come in, and required their urgent attention, which could often interrupt the flow of the conversation.
Mock-up of my questions sheet, showing how I grouped the questions to anticipate regular interruptions during interview
In order to deal with this, I had to work around these distractions by arranging my questions into small groups. This would help me to ensure that I could get answers I required, hopefully before the next distraction came. It didn’t always work, but it did help me to arrange my questioning to something of a more successful outcome.
Demonstrating value through discovery
Previous to conducting the interviews, the client had voiced skepticism around the value of interviewing clients, in the light of their decades of technical expertise, and my lack of previous knowledge of the subject matter. However, upon finishing each interview, I would collect up my notes and define clear observations from my discussion. I would the compare and contrast those with what others had said, and was able to produce a series of discoveries, which I was them able to share with the client, to demonstrate the value of my efforts by providing ideas for improving the product. These included:
A sliding scale of requirements
One key discovery was understanding the relationship between the different types of trader, which provided a scale between the amount of tickets that they dealt with each day, against the amount of supporting analytics information that they needed to deal with those tickets. The current solution had been a “one size fits all” approach, which was then tweaked as users complained that it lacked the functionality they required for their specific working style. This led to a product that was full of “experience rot”, and ran slower and slower, as more features were demanded and added. This increasing slowness of the system led to traders actually missing important trades, and a loss of potential revenue. By understanding the basic needs (as shown on the Kano model) of different types of user before the system was rebuilt, we were able to factor in the requirements along the sliding scale, without impairing the smoothness and speed of the final product.
Graph showing the sliding scale of different user types, based upon complexity of tickets against “traffic” (number of tickets dealt with per day).
A noisy user interface
Speaking to the users, I also discovered that the current user interface was very noisy – lots of bright colours and sounds vying for the user’s attention. This was again the product of the previously executed “bolted on” process, where functionality had been added upon demand, with no consideration for the relationship between different features on screen, leading to a screen full of notifications and a visual and auditory cacophony. What’s more, tickets would “pop up” on the screen, often obscuring other vital information, or other tickets. In busy periods, the combinations of tickets rapidly popping up, as well as all the colours and noises that came with them, led to a very frustrating experience.
Implementation
Having presented these and other observations to the client, I could then proceed with designing solutions to address them:
Number inputs
Interaction design around providing a way for users to quickly select and change values within the number field, helping with speed and precision of trades
For traders who needed to deal with large numbers of tickets in a short time, being able to accurately adjust values on the ticket was key. I therefore explored ways in which traders could adjust numbers incrementally for small adjustments, as well as type new numbers in for larger changes.
Ticket prioritisation
Designed an interface which allowed users to triage tickets automatically, setting up rules that would divert tickets under certain criteria away from the main interface, so that they could focus on those that they found more important. The diverted tickets would be relocated to “drawers”, allowing the user to still check in on those tickets, when they needed to.
A modular interface
A customisable screen layout, ensuring that users can tailor the screen to their needs, and be able to see all the information they need at once.
In combination with the previous two ideas, I provided a customisable, modular interface, allowing users to tailor their screen with the information that they needed, and leave out anything that they didn’t. This also prevented the need for pop-up tickets, as they could be shown on the screen using the triage system, thereby ensuring that they didn’t cover any other important information.
Atomic design system
To complement the modular layout, and to help the development team, I created an atomic design system that regulated how each component looked, worked and fitted together. The atomic design system was developed using symbols in Sketch meaning that any changes would disseminate throughout the whole system, and, most importantly easily provided an overview to ensure that colours and layout did not override the overall information architecture of the screen.
Conclusion
The client was pleased with the outcome of my work, and the new system has now been implemented. Due to the nature of the engagement, I was moved on to another project, and I would have liked the opportunity to stay on and be able to test my work more with users, so that I could have a more defined metric of success. I also hope that my work has demonstrated the value of UX research to the client, and, in future, they consider taking a more user-centric approach, instead of assuming that they can successfully dictate product success with their own experience. As a result of my experience, I wrote an in-depth analysis of how and why you should conduct better user research in your projects, using my experience on this and other projects to help inform others of the discoveries I have made.
How road safety measures show the value of revising your design work
Introduction
Having previously worked on projects where stakeholders had set a tight timeframe, and not allowed for any testing and iteration of the solution, I wanted to explore the concept of iterative design, and how it can benefit a project. I had learned as a child about the story of Percy Shaw, and how he had devised Catseyes, the reflective studs that illuminate the centre line of a road, inspired by the eyes of an actual cat reflecting his car’s headlights one evening. Using this example, I describe how Shaw didn’t just create his solution from that discovery, but went on to revise his design, test it, and incorporate new ideas until he produced the design that we know today. In the same way, projects can benefit from this approach, getting feedback on their designs, and ensuring that they suit user needs, before they are launched.
