All but the most basic web sites and online applications are really systems, and often pretty complex systems at that. Most of the projects I work on are systems – case processing, sales management, dashboards, and of course good old content management. Designing a good user experience for systems goes way beyond simple ‘user experience design’. It requires a much broader range of skills and expertise. Or if you prefer, the user experience discipline has a much broader definition than many assume… ;-)

So what makes you a good designer of user experience for systems? What sort of outputs should you be producing? What skills do you need? What does good look like?

Having just won a Design Business Association Design Effectiveness Award for a system I designed*, I’d like to think I know a thing or two about that.

(Incidentally, I’m addressing this article to UX practitioners, but if you’re someone who hires or manages such people, I hope you may find it interesting too.)

Being good at designing user experience for systems requires a combination of systems thinking, business analysis and design thinking. Probably more or less in that order, depending on who else you have on the team. Even if you have, say, a dedicated Business Analyst you’ll still need that skill set.

It’s about: being willing to read, re-read (and re-read again) the user stories and other business documentation; studying process diagrams to understand workflows and data flows; and analysing business rules to understand what can happen when – so you can translate that into what content needs to appear at any given time or context; what data or options should be available to the user at any given time (and hence what field types or mechanics might be most appropriate for presenting them); and what validation rules will apply to the user’s inputs.

It’s not enough only to consider the user. You need to understand – in detail – the business requirements and processes driving the system.

Nor is it enough just to think creative thoughts and devise concepts. You need to develop specifications. Your outputs – whether they be interactive prototypes, wireframes, or visual designs, will need to be detailed.

Sketches are fine during discovery and exploration. You’ll do a lot of thinking and develop a lot of concepts, and rule out most of them – the usual divergent-convergent thinking. But your final outputs – whether they be at the end of each sprint, or at the end of a project phase – need to flesh out the concept, describe the content, and specify the interactions and surrounding rules (“Input x is enabled when…” etc.). You may do that within the wireframes or other artefacts, or you may be writing them up separately, perhaps as UX acceptance criteria within a user story or on a JIRA ticket. But it’s your job to write them.

And you’ll need to create artefacts to show different states as appropriate – whether they relate to form inputs, content panels, components and mechanics, or entire screens. Don’t leave anything to assumption – remove the ambiguity; specify everything that can happen, when, why and how.

It’s starting to sound like a functional specification, isn’t it?

“But we’re Agile!” I hear you cry.

“So what?” I say. You still need to specify your designs.

The only difference is you’re not producing an entire 200 page document before development starts. You’re doing it in small sprint-sized chunks – although you’ll likely need to spend a fair bit of time upfront working out the overall scope, design direction, interface paradigm etc – the “fence around the field” as I call it.

That’s one of the challenges of designing UX for complex systems within an Agile process – you really need to do at least a first pass at the whole system before you have something sufficiently thought through to be build-ready. You can break the requirements down into sprint-sized – or smaller – chunks, but you almost always find your thinking about the overall paradigm changing as you go along, as your understanding of the requirements improves, and as you get feedback from user testing. Sometimes it’s just small details or enhancements to the user experience. Other times it can be major shifts in the paradigm when getting into the detail of a particular area leads you to realise that the model you started out with isn’t going to fly, so you re-think. And sure, Agile is all about being flexible and accommodating change, which is fine if you have an open-ended budget and unlimited time, or you’re happy to accept a sub-optimal user experience or a ‘bag of widgets’ product (my term for one where all the required functionality is there, but none of it is joined up – there’s no overall consistent, considered user experience). But when it comes to design changes, amending wireframes or visuals takes minutes-to-hours; re-writing and re-testing a bunch of code may take days, weeks, months even… Get the design right first – at least the broad brush strokes. But even that requires digging into quite some detail…

Anyway, back to your outputs. You may be able to shortcut some of the word-count if you have a good development team you can work with directly and involve yourself closely in the day to day development. And you may be able to – temporarily – leave some bits ambiguous, to be resolved down the line. But sooner or later you’re going to have to produce something – a prototype, a wireframe, a visual, some words – that contains sufficient detail for a developer to build it. A conversation may be enough for a simple web page, but when you’re dealing with complex systems, you need specifications. For the simple reason that there’s a lot to think through, and you need to have done that thinking, and no-one is capable of remembering it all without it being documented in one form or another, and very little of it is the sort of stuff that can be decided by committee, or explained in sufficient detail, or minuted, in a sprint planning meeting.

Think through the detail, in detail. Be prepared for that to be mentally exhausting. Forget that warm fuzzy ‘being creative’ shit. That’s for artists. This is hard work. Weigh up all the different factors that influence functionality, screen states, content, interactions, validation etc, and make your design decisions. Then document them with the attention to detail you’d expect, from someone designing the autopilot controlling the aircraft you’re flying on, or the banking system looking after your money. There is no shortcut.

Detail, detail, detail. That’s what good looks like.

Now go and read this: User Experience – Not Just a Line on the Project Plan :-)

*You can read more about the DBA Award-winning system I designed here, from where you can also download the full case study. I worked with Prospect on behalf of Dimension Data to develop a dashboard system that would enable their clients not only to monitor the health of their IT infrastructure, but also to understand what that meant for the performance of their business. My role was much as I’ve described above.