Does Agile methodology lead to poor interface design?

There has been a lot of finger pointing at frameworks such as Bootstrap for an apparent depreciation in design standards lately. But, I think that Agile methodologies have something to answer for as well.

I get the idea (and like it) of developing something quickly that can be pushed out, bit by bit, to a wider audience, testing all the while and tweaking based on user feedback.

But, the problem I think is that Agile production methodologies don’t put enough emphasis on the character and personality of a design at the start of the process. So, you can end up tweaking and tweaking something that is lacking in both these traits. Trying to add them later just looks like decoration.

There is a desire when working in sprints to build something quickly, to get it working, to test it on real users. This desire to test something that works, i.e. something that’s coded that users can interact with, skips testing the character and personality of the design with those same users.

Some things just take time

Unfortunately, design testing takes time and, it seems to me, is the area of waterfall development that is often missing from the Agile process.

Testing moodboards, mock-ups, design alternatives, asking questions about whether a design fits with user expectations of a brand, needs to happen before you build something. And that goes against the idea of an entire team – researcher, designer, developer, copywriter, business specialist – all sitting down together and working in sprints together. Sure, that process works brilliantly once a design is in place but it doesn’t if developing the look and feel of a site is meant to be part of the project.

Are you really a designer?

Another reason why design standards appear to be going down is that people like me are making too many design-related decisions. I’m perfectly capable of developing an effective information architecture. I can work with clients to really home in on what their content should be and how it should be prioritised. The problems begin however when I start to create wireframes. It’s ok to a point, as long as I allow the designer to interpret my wireframes and then test the designer’s approach with real users. And that is what I think isn’t happening. Wireframes are being taken too literally.

I’ve spent years working with really good designers and I’ve learnt to appreciate good design when I see it. I can see when something isn’t quite right and I can suggest the odd tweak. But develop something from scratch? Not a chance.

Good (visual) designers are born, not taught. I’m not comparing interface design to great illustration or musical virtuosity. That’s a leap too far. There are many people in the world that can do great design. It’s not the domain of a tiny minority, but we do need to recognise that it’s something you need an eye for (as well as a great deal of experience and knowledge too, of course).

There are two types of people in the world…

I can hear some people grumbling that I’m just talking about frills. Function is way more important than form, if you like. And, I accept, there are many millions of people in the world who genuinely feel exactly that. But equally, there are millions of us that appreciate form just as much. It matters. Not to everyone, but it does. We only have to look at the products Apple makes to highlight the point (and remind ourselves that they are the biggest company in the world while we’re doing it). If my Macbook Air had a badly designed exterior (but with exactly the same spec) I wouldn’t have bought it.

So when it comes to form and function, there are two types of people in the world. My leaning towards form is possibly somewhat akin to the fact that every grammar and spelling mistake I see makes me wince when others – often, considerably more intelligent others – breeze over them as if they don’t exist. To them, the content is the only thing of real importance. But, to me, there is beauty in a well-constructed sentence. Word craft adds considerably to pretty much anything I’m reading. It tells me something about the author’s character and personality. It might not actually be true but isn’t that what brand is all about? Trying to project aspirational attributes?

Conclusions

To conclude, I think we should be creating look and feel ideas and testing them with users before starting to build anything. Not doing so risks safe, utilitarian, characterless design becoming even more predominant.

Also, a significant number of people will make decisions about your product (whatever that may be) based on the aesthetics you use on your website.

  • Dave McRobbie

    Excellent piece Marcus – I couldn’t agree more. Stepping back, taking time and letting the creative process flow does sometimes get overlooked – as does understanding individuality in the visual and written form.

    As an aside – having only recently got away from just focusing on project delivery and now having some time to think… – I’ve only relatively recently started listening to the podcast – It’s great to know that I’m not alone in my thinking – even if the jokes (apart from the Tim Vine ones) could do with some work. All the best.

    • Kirsten

      Hiya. With regards to the comment:

      “Stepping back, taking time and letting the creative process flow does sometimes get overlooked – as does understanding individuality in the visual and written form.”

      This is not specifically an Agile problem, and it certainly isn’t evidence that Waterfall provides the necessary framework to prevent it. The issue you describe is one where the team haven’t identified where the value for the customer lies and potentially in a team where design is not embraced within the process of understanding value in the first place. And therefore it’s overlooked or underinvested.

      • Dave McRobbie

        Hiya Kirsten.

        I agree with you totally! Its a bigger piece.

        One of the issues I have seen however, is that by a studio being focused on getting work into an agile or waterfall process quickly (which is a value measure and one that all project delivery processes are guilty of) rather than stepping back and considering individuality of client need and wider team member competencies – we end up with more of the same products. Which (forgive me if I’m wrong Marcus) I think is one of the underlying points of the original post.

        BTW – great discussion piece.

        All the best

        Dave

        • Kirsten

          Hiya, I think we’re along the same lines.

          One issue with introducing Agile is that it’s often driven from the technology side of the business (the developers or CTO) whereas it’s actually an organisational issue. Unless organisations see the transition to Agile as an organisational shift then there are people and processes that are left out in the cold and feel they have to shoe-horn themselves into a way of working that was never designed or thought through for them. Hence you end up with something akin to Waterscrumfall whereby only the developers deliver with ‘Agile’. This will result in an ‘us and them’ mentality which is the opposite of what Agile seeks to achieve.

  • Marcus

    Thanks Dave!

  • Your opinion is refreshing. I’m sick of hearing UX people openly denigrating visual design and considering it subservient. There’s a sweet spot between the brand/creative process of advertising agencies, the user centred process of UX agencies, and the agile process of development agencies. I’m still searching for it. It appears to be in product led tech companies. Am I right?

  • I can certainly sympathize with these concerns. However, I think there are ways around it. The first thing is that no one said that sprints/iterations have to be the same length or have the same amount/type of output. Having a longer, first iteration can help provide the necessary big picture. At our company we also allow for “definition,” which includes initial interviews, problem definition, and big picture synthesis.

  • Kirsten

    Hi Marcus. The post does raise some interesting concerns that some designers may have but I’m a little confused by the narrative. The title ‘Does Agile methodology lead to poor interface design’ only relates to Agile impacting the interface which is a utility or function, effectively an interface is only required if someone needs to do something be that find information, perform an action, navigate to somewhere and so on. Interface design can therefore only ever be considered based on a user requirement: there must be a desire to achieve something (a goal in a user story in agile terms if you like). But the body of your post appears to deviate from interface design and talks about ‘character’ which could be interpreted as look and feel and brand which could be considered as form and not function. Therein lies my confusion.

    I’m not about to tell you that you’re wrong in your assessment because creating web products and websites that look good and work well is a difficult job and the way you get results, however that’s done be it using Agile, Lean, Kanban, Waterfall or a mixture of them all doesn’t really matter so long as you’re getting the results you and your clients desire.

    I would however say that a lot of the issues I hear with design in Agile being a problem has little to do with Agile and more to do with an implementation or (miss)interpretation of Agile. Quite often it’s because Agile has been introduced or driven by developers and the adoption has not been considered company-wide. In your case, I would debunk the myth that Agile doesn’t consider the character of the design. Agile doesn’t do anything other than advocate the following principles:

    – Individuals and interactions over processes and tools
    – Working software over comprehensive documentation
    – Customer collaboration over contract negotiation
    – Responding to change over following a plan

    Agile per se doesn’t stop you from considering the character of the design, in fact it should better enable you to design character that is focussed on the desires and emotions of your target audience which you have built out in the form of personas during the discovery phase of the project and hopefully you have plastered all over the walls of your office to remind everyone of who you’re all creating that thing for. It provides a framework to understand more about your target audience and understand what ticks their boxes which can be embraced within the design process. Different people desire different things, design changes depending on who it is targeting and therefore, the character of the design should be at centre stage of any design discussion. If the design doesn’t do it for the user then it shouldn’t pass QA at the end of a sprint – Agile is not just about function and code, it is about delivering value to users/customers (ie: all the things including design). Something that fulfils a function but is undesirable visually for a customer is therefor QA fail.

    Design can very much be a part of Agile but in the end, it’s how you chose to run an Agile project that will determine if design is correctly embraced into the process.

    • Marcus

      Hi Kirsten, many thanks for your detailed reply. In a nutshell… I think Agile offers more opportunity not to focus (enough) on aesthetics than waterfall. But, as you say, it can be very much a part of an Agile project if the project is managed properly.

  • Markus Freise

    I think, the biggest mistake was to even make a distinction between UX Designer and … well: designer. There can’t be a good interface/web designer who’s not a great UX designer in the first place, as this is his or hers whole job: designing interfaces which have a great user experience. To be somewhat cynical one could say a UX designer is a designer who lacks the taste and smooth moves of a good web designer.

    As I am considering myself to be an experienced interface designer, who even saw CD ROMs made with Macromedia Director way back when the commercial web, as we know it today, was years away, can’t stand it anymore, if some UX designer bursts out into “How much does it make a difference if the button is round and blue. People won’t notice.”

    But it is as you mentioned: If people wouldn’t notice, they wouldn’t buy Apple stuff, which was always inferior regarding the naked specs. Nonetheless today it’s the most valuable company of the world.

    Maybe it’s because the people notice way more, than UX designers would admit.

  • Cedric Dugas

    The Agile workflow can adapt to that, this issue seems more about the agile process being generally handled by technical people that are more concern about velocity that design quality.

    One of the main perks of agile (business wise) is to have increment of product faster & to optimize the works so that you lose less time working on stuff to much ahead that could change down the road. One other thing is that without real data it is hard to really tell if one UX is better then the other.

    In that mindset, in the past teams I have been involved with we built wireframes before sprint, we made it approve by execs then in the sprint the front-end devs developed the base ui & then our designer would design on top of that, often iterating on the fly.

    That brings a lot of benefits, one of them being the final result is executed by your designer & not some random dev removing the approbation layer completely.

    Anyway I know it’s an hard problem, just my 2 cent.

    • Kirsten

      Technical people don’t care about velocity. Project managers, wrongly, care about velocity. That first statement is absolutely incorrect.

      But I do agree that Agile is often introduced by technical people and not seen as an organisational change (which it should be). That can lead to the design process being left out int he cold. It’s and organisational change issue, not a technical issue.

      However, on this:

      ‘I have been involved with we built wireframes before sprint, we made it approve by execs’

      Execs are not the ones who should be approving user experience design. User experience should be testable on users and the data from that should be provided to the decision makes (execs or whatever) to decide what to do next.

      Executives are not end users and cannot speak for end users. Execs may be decision makers so adapt the process to allow them to make decisions without them insisting on including pet or vanity UX/UI which is inevitably what they do when signing off wireframes. That just sounds like a nightmare and incredibly inefficient.

      • Cedric Dugas

        Hey Kristen,
        1. We are on the same page.
        2. By Execs I meant stakeholders my bad (last job the exec was the client).

        • Kirsten

          Ah right, great 🙂

  • Aaron Lawrence

    Maybe this just shows that clients often don’t really care about design (form) that much, ie. enough to spend money on it. If they are getting the functional results they want, then they may not worry at all that it doesn’t look that great.

Headscape