Boxes and Arrows: Comments by Michael Smethurst

Michael Smethurst — Wed, 03 Mar 2010 14:43:22 GMT

Hi Anthony

First some bits I agree on:

1) there’s often a focus on shipping new features at the expense of tidying existing ones
2) the push to ship unfinished features is short-sighted; frightening users away with a promise that things will improve is a precursor to ‘brand damage’
3) any development that doesn’t include time for user testing AND accessibility testing and allow time for findings to be worked on and integrated is broken
4) untrammeled product / project managers making ill considered decisions are a massive problem
5) dogmatic scrum ‘masters’ do exist

On the first 3 I can only say that pressure for visible movement will always be with us. Being seen to get one step ahead of competitors (external and often internal) is one price we pay for competition but competition is innate to capitalism. The only hope is an enlightened management acknowledging complexity and giving people enough time to work through problems…

Number 4 I’ll get back to.

And number 5 is just an extension of a general truism; all development methodologies quickly sink into dogma. Unfortunately organisations are suckers for process, workflow and box ticking. (And as many people have asked, “have you ever met anyone who FAILED scrum master training?”) Anyway all process is a creativity sink. This is equally true of UCD which, applied dogmatically, is one of the least user centric approaches I can think of. Putting real code in front of real users (with assorted accessibility requirements) one of the best. So long as management give you time to act on the findings.

Afraid the rest of this comment has more of the usual ‘someone on the internet is wrong’ type smell about it. Apologies but…

...your opening minefield comment of “one has to ask whether [agile] was devised to treat a symptom of the larger cause: the business doesn’t know what it wants” is true but understandably true. Things change. Business priorities change, businesses merge and divest, the competition changes, *user expectations change*. Failing to acknowledge this and ploughing on with ‘big design up front’ doesn’t address that problem and doesn’t work. It also doesn’t address the fact that in a complex system it’s often impossible to judge the feel of a website until real data hits real code; design that works on paper too often breaks in reality.

(I’ve worked in the past on a music website that followed the full UCD methodology: research, personas, experience models, sitemaps, wireframes, photoshop comps… In the time it took to work through all that both last.fm and itunes shipped. Our site was 5 years out of date before it even went live.)

For fear of typing a longer comment than the original post I’m only gonna deal with your first mine (an unclear role for design) but I suspect most of the rest drops out of that plus the usual concerns about management allowing time.

You say “some [...] developers may have design skills. But that’s not a particularly common scenario”. This is either a very restrictive definition of design or just wrong. The question is: where does design happen?

Every time a developer creates a database or creates a model or creates a URL scheme or marks up a document that’s design. Writing code is design. Many (the majority?) of creative people I’ve worked with have been from the developer side of the wire.

The Google example you use is interesting in this context. Google was definitely ‘designed’ but no user experience professional or even the majority of software engineers I know could have designed it. The Google breakthrough was not the realisation that “people just want to find what they’re looking for, not learn how to drive a search engine first”. The breakthrough was making that possible. And making that possible was about software engineers and mathematicians taking academic models of citation, making the analogy to link density and *designing* a solution that used eigenvalues and n-dimensional spaces and serious maths to crack the nut. You could have spent months ‘concepting’ and taken the conclusion that “people just want to find what they’re looking for” to Yahoo! but the concept would be useless without the design and the design was tricky to say the least.

Back in the day flat websites were ‘designed’ by designers who handed over their wireframes and specs and photoshop comps to developers with the request ‘make it so’. Designers were creatives; developers just trades people. Having come across the UCD +/vs Agile arguments a few times there seems to be a temptation to wrestle back control and return to these glory days. But with the complexity of modern web applications it’s just not possible. No one person knows enough to be given overall control of design direction. This includes product/project managers, which is my easy answer to point 4 above.

You go on to say that ‘in good software development, a conceptual interaction model that has been thought through beforehand, outlines how the user navigates the system, performs tasks and uses tools in generic terms’. For a website of any complexity interaction design (together with quality copy and visual design and quality a/v) is the small part of the visible 20% of the application. It’s not an unimportant part but the other 80% of the application also needs to be “designed”.

In a later comment you say that “I personally don’t care what happens in code (though perhaps that’s just ignorant of me and I should) what matters to me is that the interface is consistent from one section of an application to the next”. For an interaction designer this is fine but again I think it’s short sighted to assume that design stops at what the user can see / feel. Taking Twitter as an example: it’s a beautifully designed service but the design insight was all about low friction communication and open APIs. Many Twitter users interact through clients and never go near the Twitter website. The Twitter interface is consistent but more important is consistency in the application / client interface all of which required design.

So decisions made further down the stack (what gets modelled, data flow, data licencing (particularly if you’re dealing with user data), url design, content negotiation / device detection, caching, document design, feed design) are not just examples of design but fundamental to a wider definition of user experience (in terms of seo/findability, website as platform, pointability, perceived performance, accessibility etc). If you don’t spend time designing that stuff then obsessing on a “consistent interface” is just painting pigs with lipstick.

To quote Steve Jobs (and why not?) “Design isn’t about how something looks; it’s not something you put onto the outside of an already-built product. It’s how you build the product, from the inside out.” In web terms it’s about design decisions all the way up the stack and working well with the design decisions of the web (statelessness, HTTP, URIs, HTML, CSS). If you’re not interested in code and not interested in technical design decisions of the web (which have moral and ethical implications) then I’d suggest you’re not a web designer and might be happier working in a different medium…

In conclusion I’d say the role of design in agile is clear. Everything is design; everything is development. Things work best when different people with different skills work together to solve problems. Attempting to rebuild the walls between design and development (even by staggering sprints) is a mistake. As Craig Webster says “A [user] story is a token for a conversation. Unfortunately very few teams actually have the conversation.” It’s up to designers and developers to have those conversations and up to management types to give them the time to do so.

***

One final point in answer to @doug’s comment: “what we do NOT do is completely rearchitect the UX each iteration – UX is just too fragile and expensive to change”. Yes UX is fragile and expensive to change but it’s actually a *lot* cheaper to change than any other aspect of a web application. Web apps are a layer cake of database, models, controllers, views and css. The further down the stack you make changes the more impact on the layers above. Changing mark up + css is much, much cheaper than remodelling your database eg. Not that constantly changing your UX is a good thing but the pain point is usability/consistency not designer/developer overhead.

Michael Smethurst — Fri, 07 Jan 2011 20:40:22 GMT

@anthony – I suspect we’re not about to agree on this but here goes anyway…

Firstly my “five years out of date” comment was misleading. I didn’t mean the project took 5 years. From (pained) memory it took about 12-15 months. The point I was trying to make was that during those months iTunes took off and Last.fm happened. The market changed and user expectations changed. It was 5 years out of date because it felt like the market moved on 4 years in those months. Which is often why businesses “don’t know what they want”; or rather why businesses change their minds and why agile is better suited to cope with this.

The other major problem with that project was despite all the personas and wireframes and sitemaps and photoshop comps by the time we’d written the mark up and added the css the data we had couldn’t be queried in a way that allowed us to build the product we’d planned. Much of the project went in the bin and what we ended up shipping was a very small subset of what had been intended. Starting by designing the data model and working up just lessens the pain.

I’m not blaming UCD for this and not saying that some design shouldn’t happen up front. I am saying that designing from the visual layer down is much less efficient and scaleable than designing from the domain model up.

I should also say that this experience isn’t just confined to my current employer. I’ve seen plenty of projects fail in plenty of different organisations because they’ve spent too much time designing the skin and not enough time designing the skeleton.

We (designers, developers, IAs) spend a lot of time with paper and pencil (or more often whiteboard, pen and post-its). But when it comes to user testing web design there’s no substitute for working code on top of real data. You can theorise interface details til the cows come home but in my experience trying to second guess how the application will ‘feel’ when the data hits the code is just misleading. Things that have worked in my head and on paper just felt wrong when seen in reality.

I wouldn’t say I’m fixated on on the prototype being high fidelity; just that writing prototype code AND real code is inefficient so why not make the prototype the real thing? As (possibly more) important is the use of real data. Interfaces need to evolve as the data volume increases. Taking my current project as an example, views that used to work when the system had a low volume of data now need to be redesigned as more and more data hits the back end. Attempting to get the design right without being able to experience the experience is too often futile.

Even in the simplest terms different browsers have different capabilities and different configurations and different people set them up differently. Again, the sooner you can see real users with real setups interacting with your application the sooner you can see what works and what doesn’t and make changes. Does the fancy javascript/ajax interface degrade gracefully? Is it accessible to those with javascript turned off? Are the pages accessible to users and search engines?

So onto design and who does it. I’m slightly confused by your statements: “Naturally, every team member’s work has an impact on the user’s experience. Only some work at the part the user touches.” I suspect it’s more accurate to say only some work at the part the user consciously touches. Taking my earlier example of HTTP caching. It’s a small detail but set up incorrectly the impact on UX (in terms of perceived response times) can be immense. It’s even worse on mobile where lack of caching means more return trips to the server and bigger data bills come the end of the month – which has to be a user experience issue?

Possibly the fact that “some [people] have a job title that suggests their primary function is to worry about [ux] before all else” is the problem here? Maybe we just need to go back to visual designer, interaction designer and information architect and embrace the fact that it takes more than those to make a user experience?

Taking a wider example from the project I’m currently working on. We have a single data model but with different business logic and ux on top we have 2, 3, 4 different ‘products’. The important point is that the domain model which underpins all of this is built taking user’s mental models into account. And my point is user experience starts with what you choose to model. I can’t think of a better link than Tom Coates’ Age of Point at Things [1] which talks about data modelling as the starting point for user experience (comparing ‘episodes’ on the BBC ( a concept that exists to users but which is not in any BBC business systems) to the lack of book works on Amazon books and performances of songs on iTunes). Taking a user centric approach to domain modelling and building upwards and out from the data model enables freedom of movement in the layers above which allows the site to evolve over time without changing the underlying model.

I’ve seen lots of projects built in the opposite direction; taking the ‘ux’ layer and working down the stack. That works fine for a first iteration but because the underlying model is designed to build a specific interface it gets trickier and trickier to warp the data model as the product evolves. Eventually the cost of changing the data model to cope with interface updates gets prohibitive and the whole stack needs to be rebuilt.

You go on to say “some disciplines [..] are more tuned into that world than others. No database architects I’ve known are focused on or skilled at designing a GUI that is easy or fun to use.” The point I’m making is not that dba’s are gonna build beautiful guis. That breed of unicorn may or may not exist; like you I’ve never really met any. The point is they do design too and that design has a ***fundamental*** impact on user experience. If they model the wrong things no amount of shiny css is gonna make that better. And correcting any mistakes they make is far more expensive than fixing the gui. Because, again, the further down the stack (css > markup > controller > model > database) you make changes, the greater the impact on the layers above.

I can’t really comment on the Apple example since I honestly have no experience of how they work. If it is from photoshop comps I fear that just depresses me…

On the final point about API design, I honestly believe that no-one benefits from personas. They’re an abstraction of real people; the world has quite enough real people without resorting to characature. And no persona is gonna give you the insights you need about modelling works not products or episodes not versions. Again a good api is reliant on a good data model but again the api (as user) experience relies on good http design, good document design etc. Much like experience for humans it’s a good mix of skills that makes an API work; no one person knows enough to make everything tick.

[1] http://www.plasticbag.org/archives/2005/04/the_age_of_poi…