Things what I writ

I sometimes write nonsense about things to try and sound clever

There is no user experience design process

Whenever I look at a new project and I’m mapping a process to the task in hand, I’m reminded of those cutlery deniers in the Matrix. There is no user experience design process.

That’s not to say there aren’t a few processes to choose from. It’s easy to argue that user experience design doesn’t follow process, because really, as Chandra Harrison pointed out the other day, the process is really user-centred design. User experience is really, well, the user experience. Except, I call myself a user experience designer, and when it comes to ‘designing stuff’ that addresses user needs, identifies requirements, suggests solutions, optimises performance, but also needs to be designed efficiently, predictably, and consistently, there’s got to be a reference model for how a design project runs. Well, I say there’s got to be, it’s more like there should be.

Building a design framework

Whatever process you use, if you’re just using one, that seems to work for everything, it might not really work for anything. At least, it might have worked for one thing, but a singular success does not necessarily define a re-usable method. Much better to understand and review previous design projects to understand which approaches worked best in specific instances and then build a design framework that actually supports building your own, modular process to support multiple projects.

There’ll be traditional activities in there, identified from the ground up, like research, design workshops, competitive analysis, wireframing, persona definition, prototyping, and so on. There’ll also likely be a more generic process pathway within which those activities sit. Think ‘discovery’, ‘ideation’, ‘visualisation’, that kind of thing. How you put your framework together largely depends on what kind of projects you, or your organisation, run, but you’ll only know what the elements are if they’re based on a thorough understanding of prior and planned work. How rigid the resulting framework is will depend on your client mix and how diverse your projects are. The flexibility in how you allow staff to pick the best, most relevant elements and roll their own process to suit those clients and projects, is what makes your framework delightful, rather than frightful.

Framework schramework

I should point out that everywhere I’ve worked as a designer in the last 15 years or so has had a project on the go to build the framework I’m talking about. The ones that don’t work tend to focus on deliverables between activities and phases. The ones that work better tend to be more focused on the definition of the activities themselves and what value they add. And, of course, they’re probably redundant anyway, since lean and agile anti-processes are surely going to take over the world. Either way, I’m looking forward to seeing the next one. I’ll let you know how it goes.

Usability and the Business Analyst: Smuggling UX at the UK IIBA

There’s a new contraband changing hands in clandestine boardroom exchanges in the most powerful businesses in the land. It doesn’t fall off the back of a lorry, or get swept up on the beach, following the sad demise of some stricken thought tanker, however. No, this new currency is traded under the cover of business analysis. This illicit commodity is user-centred design

I recently attended an event run by the UK chapter of the International Institute of Business Analysis, hosted at Credit Suisse, in their rather nice offices at Canary Wharf. The event was a panel-based discussion of how user experience and business analysis might gracefully collide, somehow becoming something more than the sum of their parts. Put another way, how does user-centred design affect the business analyst?

The panel

On the panel were erstwhile and engaging practice professionals from both sides of the collision: Cennydd Bowles and Chandra Harrison, with many years in user-centred, experience and interaction design (other design practices are available) and Jake Markham, who built the business analysis and design practise up at Credit Suisse. It was chaired by Nick de Voil, from De Voil Consulting, who conveniently bridged the gap between user experience and business analysis.

Nick Dunlavey of Information Architects, who had invested significant effort in pulling the event together (largely crowdsourced via twitter, incidentally, in case you’re wondering how a meeting of UX and BA professionals in an investment bank gets put together), kicked off proceedings in the plush 7th-floor theatre with an admission. He has been smuggling UX into projects. Appropriately, he’s been using Cennydd’s Undercover User Experience Design book as a reference to do that, and thought it would be a good idea to try and link usability and the business analyst.

To set the context for the discussion, Chandra and Jake took some time to talk about, respectively, what user-centred design and user experience is and where we are with it right now, and the development of the business analysis skills and competencies framework for Credit Suisse.

Understanding user experience

Chandra gave a whistle-stop tour of UX, from its mostly overlooked early development in product design to its subsequent and most recent focus on user satisfaction, via world war one biplanes, personas and skills matrices. She was careful to describe user experience as ‘just a term we use at the moment’ and to be clear that ‘user experience’ is not a profession, but, rather, it simply describes ‘what users experience’. What we really do, as practitioners, is apply user-centred design as an approach to system design that supports those experiences. As it turns out, most of the tools and techniques we use to do that are very similar to the tools and techniques that business analysts use, but, critically, we talk about them in very different ways. It might be rather too simplistic to say that business analysts focus on business and user experience designers focus on users, but it’s definitely the user that is the differentiator. The depth of understanding and appreciation of user behaviours, gained from years of observation and dialogue, is what user experience brings to the business analysis party. And then eats all the canapés.

Business analysis and user experience

Following Chandra, Jake was also keen make an admission before he began his talk. He is also a ‘professional smuggler of user experience’. Since Jake is responsible for defining the activities of the business analysis and design group at a company like Credit Suisse, this is good news indeed. In talking us through his own history at the company, we got an invaluable insight into how a global investment banking business is defining its business analysis function and how closely that may be aligned to user-centred design practices. Ultimately, the business analysis function is about identifying needs, collaborating on requirements and facilitating solutions, but it’s focused clearly on the bottom line for the business and the customer. Conversely, the user-centred design function is about identifying needs, collaborating on requirements and facilitating solutions, but focused clearly on user needs. This means that there are clearly opportunities to embed used-centred methods into the business analyst skills and competencies framework and satisfy goals for business benefits and enhanced user experiences.

As I read the definitions of the four roles that have evolved from Jake’s business analysis taxonomy, I was simply changing the job titles for those we use in user experience and the descriptions were pretty consistent. For Business Architect, read Information Architect and you’re nearly there. In line with a comment Cennydd later made about the demise of specific ‘user experience’ roles, I don’t really see the need for the fifth, UX-specific role Jake suggested they might need. Rather, the user-centred design methods and practices should pervade across all roles.

In the middle of all this, Jake also put up a slide that had some enormous numbers on it that spoke to the scale to which a global investment banking business like Credit Suisse operates, at which point I had to check I was wearing the right glasses.

Questions, answers and opinions

On to the panel session itself, and thanks to a brief introduction by Nick, I think I now know what a lasagne panel is. I can’t imagine why I never knew before.

The debate was eloquent, lively and, with the inclusion of Cennydd, was determined not to just turn out stock answers or platitudes. For the most part, the panel vehemently agreed when questioned on things like the business benefit of usability, quantitative measurement, accommodating user requirements without scope creep (BAs love scope creep), and the perception of user experience design operating exclusively in the digital space, on web and web apps. One of the emerging themes was the business benefit of creating ‘value through change’ rather than working to functional requirements. I can’t say I grasp this concept well enough to say whether I agree or not, but if it means understanding user needs, and designing, possibly disruptively, for that, then I’m all for it.

I’ll be honest, I took more notes when Cennydd spoke than when others did, since he catches the zeitgeist of my profession better than anyone else right now, but I did admire Chandra’s enthusiasm and deliberately wider view of usability and Jake’s measured, literate and erudite responses. However, Nick de Voil probably expressed the relationship between user experience and business analysis best:

User experience practitioners have permission to ask people how they work, operate, and do what they do. This approach has emerged as accepted practice in the last few years and it is this that makes them a powerful ally for business analysts.


As I have spent a number of years as a globalisation manager for a large corporation, I was amused to see that nobody wanted answer a question on globalisation strategy. I think we all know you might as well ask for alchemy on toast. I was also reminded, from previous work with another investment bank, that if someone from a global trading division asks a question, you need to be ready. They are scarily efficient in their questioning and can spot flannel through walls of lead.

If you thought about going to this event because it had ‘UX’ in the title, but didn’t go because it had ‘BA’ in the title, you missed a trick. Both our professions require a broadness of understanding that can only be developed through immersion, discourse and appreciation. Many thanks to Nick Dunlavey, the UK IIBA, Credit Suisse, and, of course, the panellists for a thoroughly enjoyable and enlightening evening.

And there was caviar. You’ll go next time, won’t you?

Undefining ourselves: More might be less for user experience design

As I was reading through Jeff Gothelf’s blog entry on the mythical user experience visual designer unicorn, I thought way too much about the current apparent need for user experience professionals to wear more than one pointy skill hat in order to somehow make themselves that much ‘better’.

In a nutshell (which, by the way, is a cleverly crowbarred reference to my own developer background) it seems to me that the more skills we pursue, the less skills we can practice and develop. Under a rather broad categorisation of ‘user experience’, which I’m not even going to set the boundaries on, because I still don’t know what they are, there are a huge range of techniques, skills, practices and methods that are constantly evolving and shifting in response to needs, innovations and opportunities. We learn, use, modify and generally make our best use of those techniques and skills, to help us solve problems and design solutions that we hope make the world a better, more delightful place. And I think that’s enough to be going on with. At least, in terms of a value proposition for a User Experience Designer.

There is a tendency for us to refer to ‘full-service agencies’ as some kind of 7-fingered, flat-footed cousin and the very idea that they might make a claim to be able to provide user experience expertise is roundly scoffed at. Which seems a contrary position, if we can be quite so pleased with our own ability to write code, build platforms, deliver compelling visual designs and so on, effectively pitching our own ability to full-service clients. If we’re making this shift by design (which, by the way, is a woefully crowbarred reference to my own design background), then the strategy is somewhat grab-bag. User experience design can be a hard sell, but it has a certain purity of intent that can be evangelised. As we seek to extend our reach, that intent becomes less clear.

Maybe we are all just ‘designers’ after all, but if that’s true, I’ve got loads of profiles to update.

listening post: new order – senses

Writing to be read: A workshop on being a better writer

Martin Belam and Cennydd Bowles have written popular and successful books, articles and blogs on user experience. On Tuesday evening, I attended a writing workshop, where they shared tips, tricks and best practise for ‘better writing’.

I write too much. When I write about an event, I fill the page with clever, but meaningless sentences. Seeing the details of the workshop, I thought it would be a great way to learn from others and share opinions on what makes a better writer. It ended up being all that and more. It was an insight into methods and practices that Martin and Cennydd use in their own writing, highlighting that personal approaches to writing differ, but common creative techniques and some rigorous editing can nearly always improve output.

First off, Martin shared some of the tactical armoury he has developed through his own writing. He focused on tips and tricks for writing to be read and was able to provide some excellent examples of the dramatic impact simple devices can have. Some of his advice was common sense, while some was quite crafty. Some was plainly evil, but, nonetheless, common practice, when writing with particular targets in mind.

Cennydd, on the other hand, wanted to help us understand that after writing, the real work starts. Editing your content is just as important as writing it. Through a series of classic examples and anecdotes from his own experience, he gave practical advice on analysing and improving your own writing, through careful, considered editing. In common with Martin, Cennydd also was keen to make the most important point of all: if you can’t speel, please don’t write, especially if your grammar do suck.

It was thoroughly enjoyable evening, with practical, actionable advice. Clearly, there is no one ‘right way’ to become a better writer, but if you can learn from others’ experiences, you can, at least, take steps in a better direction.

[This post is an edit of the previous post ‘This title is clever but pointless and inefficient’. It is an attempt to put some of the learning from the writing workshop into practice and so it’s not a great post, more of an exercise. If you prefer one or the other, leave a comment. You might not like either of them, which is more likely]

This title is clever but pointless and inefficient

This is the post I would normally write about being at an event in the city with a collection of like-minded individuals who were compelled to attend to on the promise of solace at their smiting of writing with encouraging words from the scribers of note that can say what they wrote with articulate summary, a sprinkling of chummery and, not least some encouragement, wrapped up in wit, delivered in earnest, with meaning, to whit, I give you a paragraph to be used as example, to print and to squint at in lieu of a sample of how you could simply just dribble away like a gibbering goon for the rest of the day.

Except, I now know better.

This evening I attended a workshop run by Martin Belam and Cennydd Bowles, which, ostensibly, was about being a better writer. That sounds like a rather lofty and grandiose concept, but, you know, I like those. Realistically, the workshop was more about personal approaches to writing, learned writing skills, need-to-know and evil-to-use devices for being read, and a heavy dose of editing. Oh, and spelling. And grammar. Which, I plainly flout irreverently and irreconcilably and even irresponsibly. In fact, there were so many golden nuggets of ‘better writing’ advice that I didn’t even have time to flippantly flap about it on the twitter.

Not really knowing what to expect from the evening, I did approach it with an open mind, and an open bottle of Corona. I was hoping that I might get some opinions other than my own on what might constitute good writing and take those opinions away to inform my future output. I did get that, but I also got a rather delightful insight into the methods and practices of two writers that I rather admire. If were to make some dubious football analogy at this point, which I am going to, I’d suggest that Martin’s approach was that of a wily, crafty, tactical midfield genius, who has a great eye for an opportunity, knows all the tricks and can pick out the killer pass most of the time. He’s always the first man to be picked, notwithstanding his occasional tendency to argue the toss with the gaffer over formations. On the other hand, Cennydd would be more of a silky, clinical, methodical kind of player. While apparently effortless in his command of the ball and organising the team (for he does wear the armband), he will be the one on the training ground under the floodlights at 2a.m., repeatedly kicking a ball at a wall until he can predictably hit the same brick every time.

All of which is just a way to say that when describing how to be a better writer, you necessarily end up describing what you’ve done to try and be a better writer yourself, and this will be different depending on who you are. Martin and Cennydd described quite different experiences and approaches, but they shared a common aim. Clearly, there is no right way to become a better writer, there are many right ways. However, what this evening demonstrated is that if you want to focus on a few of the many, some of those right ways are more righterer than others.

Tomorrow, as an exercise, I shall mostly editing the life out of this post before publishing it again. It will be like harvesting antimatter with a sock.

Expose yourself – design workshops in the real world

When I uploaded my slides from the recent IA Summit in Denver to slideshare, I had particular problems with uploading the speaker notes, which, still now, are not available. I’m a great believer in using simple slides as a visual enhancement to a spoken narrative, and so when those slides are posted on their own, there can be some strange interpretations.

In particular, I have one slide in that presentation which simply says ‘Expose Yourself’. On its own, it could be read as something of a mid-life crisis admission in a magistrates court, but in my defence (pun intended), it’s actually part of a series of slides that try to explain the benefits of opening the black box of design, to encourage collaboration with clients and stakeholders to maximise brain power and increase efficiency.

I recently worked on a project that had a quite specific definition of the design deliverables that were likely to be required, before we’d even understood the problems and thought about solutions. This sounds bad, but really, it isn’t. When we’re defining a statement of work that clients can agree to and sign off, especially for newer clients, we’re not yet in the position to sell them a period of time that’s largely undefined, that we’ll somehow magically fill with analysis and design. Pragmatically, we have to describe something tangible for delivery, based on our previous experience of similar projects, that is meaningful and understandable. Critically though, that ‘tangible something’ has scale – and that is where it gets interesting.

On the project in question, the design deliverable was pretty well-specified from the outset. But following the results of focus groups, it was clear that we needed to spend some serious thinking time trying to understand what the deliverable really needed to be – which was potentially quite different from what we’d anticipated. The scale of our ‘tangible something’ was measured in days, and in order to set our new course, we had to agree on the best use of those days. In this case, we proposed that to understand that, we should get all the project stakeholders to bring their thoughts and ideas to the table and that we spend a day working together on defining our goals and objectives and thinking about how that looks when we talk about structures, clusters, boxes and arrows. Yes. A design workshop.

Design workshops can be super-effective for clarifying objectives, surfacing ideas, analysing research outcomes, using up flip charts and making swift progress through design challenges. But they are not for everyone. They’re not for all clients. They’re especially not for all designers. While more than one head is almost always better than just one head to solve a problem, there can be a reluctance on the part of professional problem-solvers to allow others to collaborate with them on that most cerebral of tasks. That’s why I say you have to expose yourself. Let clients, stakeholders and anybody else who might have an opinion be part of your process and maximise the benefit of all those brains being in the room. When you’re steering a new course for your project ship, it should be all hands on deck. If you want to hit new project targets, you should have all your brain-wood behind one arrow. If you want to continue with ridiculous project metaphors, you should all, well, actually, forget that one. The point is, design workshops really work, and if you’re not doing them, especially when you need to corral project stakeholders and think about design direction, then I really think you’re missing a trick. In this case, the workshop enabled us to clearly define the design requirements, scope out the next phase of work and turned on at least a hundred lightbulbs over people’s heads. In the end, just talking through design propositions in the workshop radically altered the client’s expectations for how their business could position themselves in the marketplace. We’re going to do another one soon, where I’ll expose myself some more, but better to be outed in the conference room of collaboration than stuck on my own in the black box of design.

Lean UX: The UX you wish you were doing

Jeff Gothelf, Director of UX at TheLadders.com, has a great proposition for what he is calling ‘Lean UX’, which reminds us what’s great about user experience design and how, potentially, we’ve over-specified it.

His central proposition is that it’s about time we got back to looking at experiences, rather than deliverables. Deliverables help us build commodities and describe solutions and actually, they can be pretty handy to work backwards from when we’re selling into a client.

The trouble is, deliverables can also define our outcomes and we often simply work towards those outcomes, filling in the boxes as we go. I can do that. I can do that on my own, in a dark room. And then I can ask users whether it’s any good. But really, we’re missing the experience design opportunity – to get those users at the heart of the design process.

All Jeff is really advocating is that we stop for a moment and remember what user experience design is about – solving problems. You don’t solve a problem by simply picking the right deliverable. You solve a problem by understanding the problem, engaging with the user and having a conversation.

Jeff’s method includes quick conceptualisation, early collaboration and a distinctly unselfish approach to design success, but what keeps it simple is that he doesn’t focus on artefacts, documents, or whether you want it in Visio or Axure. Because that’s not the point. It’s about:

  • Control: giving it up isn’t giving it away, you’re still the ‘keeper of the vision’
  • Momentum: keeping everyone engaged and motivated
  • Quality: not compromising on finding the solution
  • Feasibility: keeping an eye on implementation (but not the documentation!)
  • Filling the blanks: the more you talk, the more you see


To quote one of the quotes he quoted, “Speed first. Aesthetics second” – Jason Fried of 37signals.com.

I’m paraphrasing here, so to get the full story, check out Jeff’s presentation.
Lean UX: Getting out of the deliverables business

View more presentations from Jeff Gothelf

If you want to hear him talk about Lean UX in person, he’s at a number of speaking events this year, including the IA Summit in Denver, but I should probably mention that there’s also a scintillating discussion of the value of thought in experience design happening at exactly the same time, so if his session is full, perhaps you could consider that one instead.

Building theme-based information architectures

There is often a temptation to dive into information architecture design based solely on acquired knowledge and a well-articulated business objective. It’s quite possible to produce meaningful taxonomies and content structures in this way, especially for discrete, closely scoped projects. However, some of the most effective structures evolve when iterative analysis of research findings and discussion outputs start to surface emerging themes.

I recently worked on the development of a new sales and investments channel for one of our financial services clients. A sales and investments channel in of itself is not a particularly unusual proposition and there is a depth of experience within the team that might predict some of the outcomes. We might even consider sketching out the concepts in our heads just to start the conversation, since the business objective is reasonably clear. In doing that, we might even get it done quicker than anybody planned, or budgeted for. I might even get home in time for tea.

How we really maximise the potential of the design phase is if we take the insights from a well-executed discovery phase, invest meaningful time to digest and analyse the messages we’re getting from customers, and we start to build up a picture of an ideal customer journey. I’m not talking here about spending a day in a dark room with a stationary cupboard’s worth of post-it notes and walking away with a full site map. All we should really be aiming for at the end of an initial design session is identifying those emerging themes and understanding how accurately they reflect the voice of the customer. Themes are really just a logical clustering of questions, statements and pain-points related to a customer’s interaction. Since they’re deliberately vague at the early stages of design, they’re not distinct categorisations with well specified hard attributes, but more of an expression of the customer needs and desires. If that doesn’t sound pompous enough, I’d also suggest that they often describe the soft attributes of the customer’s emotional engagement with the site, for example, ‘I’m worried about the future’, or ‘I need help on this’. Identifying these themes early provides a clear customer-centric reference when iterating into task-based journeys and navigation models.

Themes are also a great way to solicit empathetic feedback. It’s more meaningful to describe a potential customer journey to a client, for example, if they can clearly empathise with the customer. Using needs-based descriptions with more open language, through themes, it can be much easier to evaluate a customer journey than by simply referencing a label on a navigation entry point. Consider the difference between ‘Protecting my future’ as a theme and ‘Savings’ as a label. While one might not map directly to the other, there is still a much clearer expression of the customer need through a theme-based approach, which sets the context for discussion and iteration.

There are number of approaches to how we take discovery outputs and begin to build out information architectures that place the customer at the heart of the discussion. Using a theme-based approach is one of those that I rather like and it has proved successful in articulating the voice of the customer, particularly when talking with clients. While this has been a brief outline of the approach and some of the benefits, feel free to contact us to find out more.

inheritance in user experience design

by which, I mean, inheriting someone else’s user experience design, or proposal, or thesis, or presentation, or, even, 5 year plan. there is nothing quite so painful but satisfying as developing your user experience methodology and describing, in the most insightful of prose, the application of the process unto the design challenge that is the growth target that begets the business that spawns the project that produces the artefact that describes the outcome that provides the design solution. from whence that design solution was so eloquently detailed is the brainism that you channelled and distilled and expertly crafted into methods and practices and timelines and checkpoints that spake of some experience alchemy magick’d up from your mind cauldron.

in other words, its nice to define a process that supports a practice that enables you to deliver against your goals and make the online world that little bit better each time. actually, that last bit might be a rather grandiose and pompous blart, but without there being kind of user experience light at the end of the funnel towards which we steer the online improvement charabanc, why would we bother?

therefore, having just said whatever I just said there, it’s a significantly greater challenge to mind-mangle a process design when it actually begins as someone else’s. I’m currently co-working on a proposal for developing an experience design practice that helps enable a business transition. except that proposal is someone else’s and I’m collaborating on the further development and enhancement to get it to where it ends up on a projector in a boardroom and people start raising their eyebrows and checking their iphones for status updates from farmville, but its a good challenge. its also a challenge that’s likely to make the outcome more successful. in this case, the two heads are much better than the one head. the one head being mine.

just try everything

there is an option during an interaction with a particular screen, page, interface, device, port, socket, panel, window etc., that can be so effective that its a wonder we don’t do it from the outset and avoid all that well-thought-out user experience nonsense. its the option I most often select when I’m beginning to feel the vein on my forehead and there’s small beads of ‘stay calm’ sweat forming on my temples. more often than not, its when I’m trying to find the enhancements panel in window media player, or wondering why on earth something that used to be quite so simple in windows XP needs to be quite so appallingly difficult in vista, but quite often, its at the point when I have piece of hardware A that need to somehow interface with hardware B in order to successfully deliver experience C.

its normally at that point I just try everything. this is actually more successful with hardware issues since notwithstanding the screwdriver/electrical outlet scenario, most should-be-compatible-somehow hardware interfaces allow you do mash them together in any number of ways before doing it the right way. things don’t really get broken much and there’s not very often a knock-on effect to other resources. consider my vein-throbber today. I was only trying to wire in my previously perfectly serviceable 5:1 speaker system into the back of my new desktop system – both dell. of course, since the last computer, they’ve changed the sound card interface and so it all looks a bit different, although its all a bit the same, its just that the 6 jacks plugs and 1 I/O cable for the front left, front right, rear left, rear right, center, subwoofer (I have to say them all out loud like that because the old soundcard configuration utility spoke them out like that like some teutonic sat-nav for audio hardware) now don’t have the same number of sockets and boards and interfaces and things like that to plug into. but they have some of them. needless to say, crawling around the back of a PC with a torch when you’re supposed to be analysing financial consultancy data outputs doesn’t really have a long attention span, so the temples are glistening pretty quickly. I tried a few insertions and extracted myself from under the desk, hitting my head in the process, to see what was coming out, but it was variously a fuzzed warbled cross-phased back-to-front tinny bass calamity of an Aimee Mann track. 3 or 4 swaps and re-insertions and head bangs and torch positionings later, there really wasn’t any progress, and the markings on the interface panel that were supposed to somehow help me out were just making it worse, since they just appeared to be crop circles to me. its at that point I decided it was probably worth the risk to my 800 quid desktop if I just tried everything and anything and just wrapped this sorry exercise up.

needless to say, as soon as I just randomly flapped about with whatever cables and plugs I had in my white-knuckled fist at the time and crammed them into the nearest probable orifice, then hey presto, goodbye caroline. I should have just done that in the first place and saved myself the bother. which is what I subsequently did with windows media player. so craftily obfuscated are the enhancements that rather than navigate a series of contextual menus or follow a meaningfully and meticulously signposted user journey to the graphic equaliser of beelzebub, I just randomly clicked all the buttons on my mouse at stupid speed across all the panels in the media player container. and it worked. I saw a fleeting reference to a fly-out menu that said ‘enhancements…’ and followed that menu thing all the way to frequency nirvana.

so now I’ve got my sound balanced exactly how I want it, and my speakers are working just fine thank you. once I’ve rebuilt the music library I deleted in the process, it’ll be great.

listening post: nothing – I deleted it all
Archives
Categories

Share