Connect with us:
Thursday / November 23.

The Latest Event Industry Insights

Marrying UX, Design and Development

After more than 2 years of working on our product, I’ve finally gotten the chance to slow down to a pause in order to look back and reflect on the road travelled towards its development.

I was recently given the opportunity to speak at the UXSG Conference 2014, which in a way is what actually forced that pause and reflection. And I think it was well worth it and high time for such an activity. We have therefore looked back on what we have been doing and tried to formalise it into a model (or philosophy). The result of that is what we are calling MUDD — Marrying UX, Design and Development, and this post is an account of that review.

What is MUDD and why MUDD?

Fundamentally, MUDD deals with project management in a Product Development Lifecycle (PDLC) context. As such, MUDD’s intention is, very humbly, to make the progress of a project smooth and its completion successful (where “successful” is for you to define) while keeping the team working on the project happy and in good spirits.

In the more specific context of PDLC though, this means building:

  • better products with better UX and Design
  • products which are better aligned with what the user/client/owner/stakeholder needs or has in mind
  • products that can respond to change
  • products that keep improving

Because after all:

  • A better product -> happy owner/client -> happy team -> happy users -> happy people -> a happier and better world!

So yes, ultimately, MUDD has people at the centre of its attention, on “either side of the product”:

The current context

Today, in the world of product/software/website development, we are in a very particular and interesting context where 2 disciplines have come to be in a position of strong influence. These 2 disciplines are:

  • Agile
  • UX/Design

Note: I use UX/Design as a general term to encompass UX Design and Visual Design.

As a result, MUDD is very much about marrying UX/Design with Agile development.

The “problem”

This marriage has been viewed as being quite a difficult and problematic one and has been the topic of quite a number of discussions over the past several years. I believe we are slowly reaching a consensus though (i.e. that there is nothing incompatible between the two), but it helps to understand this perceived problem by having a brief understanding of the 2 disciplines, their origins and their purpose.

Agile

Agile (Agile Software Development to be more precise) formally came into existence in 2001 and was very much a reaction to the Waterfall model. It is a “conceptual framework that focuses on frequently delivering small increments of working software” (Wikipedia) and came about as an attempt to:

  • Achieve efficiency, leanness and removing waste from the process
  • Respond to change and unpredictability
  • Develop the right product for the user

Unsurprisingly, in the fast-paced and fiercely competitive world of commercial new product development, Agile came to be seen as a very good model to follow in order to stay competitive. Agile helped companies innovate fast and go to market fast, by developing new features and products quickly, flexibly and efficiently.

Unlike the Waterfall model, which is a phase-driven sequential approach where you finish one phase completely and then hand the work over (usually in the form of a very comprehensive and thick document) to the next team until you reach the end of the “line” (a literal replica of the industrial manufacturing process, dealing with physical products), Agile focuses on the essentials and takes an incremental and iterative approach through faster and shorter development cycles (tapping on the specific characteristics and particularities of the digital medium in combination with the Internet).

Adapted from…

 

Adapted from…

 

So Agile is a faster, more lean and more efficient model (in most cases and compared to Waterfall).

However, with the rise, empowerment and sophistication of the user (that came about only during the last decade or so in the specific case of online and digital products, but even earlier in the case of physical products in general), simply being lean and efficient was no longer enough to stay competitive. Today, products are expected to be usable and user-friendly at the very least, and a beautiful and delightful user experience that results from a product that is easy and pleasant to use is becoming the norm.

This is the context within which UX/Design has emerged to become a highly valued discipline.

UX Design

UX Design (UXD) is a very broad term which encompasses designing how a person uses and interacts with a product, in such a way as to help them achieve their goals (Source). UXD is therefore, all about User-Centred Design (UCD), i.e. putting the people first and at the centre of the problem. Good UXD is all about how your product works, looks and feels. Optimise these 3 aspects and you are on the right track to creating a good product.

As a brief overview, here is a simplified UX process, based on Cooper’s Goal Directed Design:

Adapted from…

 

Back to the “problem”

The problem, I think, stems from the way we have been looking at things, which is that UX looks like Waterfall: phase-driven, heavy and slow (or at least this has been the perception of it), while Agile on the other hand looks fast, in-motion, dynamic and is iterative.

 

We believe this is not the right way to look at things, and that we should look at these 2 activities on their most fundamental and basic levels instead, which is that UX/Design is Thinking, and Agile (Development) is Doing.

 

I do appreciate the fact that this is an overly simplified way of looking at things, but fundamentally, this is what these two disciplines are really about. The output of UX/Design is ideas, thoughts, plans, and visuals, to be followed and acted upon, while the output of Development is the build, the constructed work, the end result.

So, the question here is really about syncing, and I would even dare say synthesising, the Thinking and the Doing. And this is a craft and requires practice and balance in order to be beautiful.

As an analogy, think of the extreme example of a craft person at work, e.g. a wood sculptor.

Source

When the wood sculptor is working and in the flow, what is happening is:

  • He is constantly assessing the current situation and thinking of what to do
  • He then makes a decision and acts based on this assessment
  • Which results in a change in reality and situation
  • Which in turn results in his re-evaluation of the situation
  • Which updates his thinking
  • Which informs his next decision and action
  • and so on
  • and so forth…

 

This is all happening in synergy and is a beautiful process. Now, imagine having to achieve this same beautiful process and synergy with the sculptor being “broken down” into several persons (basically the team members), with each member having a specific and specialised role and tasks. From this perspective, I think you can appreciate the difficulty of the task at hand, as well as the beauty of the result that can be achieved, should this synthesis of Thinking and Doing be successful.

Ultimately, this is the type of efficiency and beauty we aim to achieve with MUDD, where everyone is in synergy and things flow.

And that’s what people really mean when they say, “Let’s work together as a team”. It’s about several individual persons working together and achieving one goal, as though they are one entity.

Changing the way we look at things therefore reveals that it’s not a “problem” of trying to integrate a slow and heavy process with a fast and iterative one, but it’s the challenge of synthesising, synchronising and balancing the two activities of Thinking and Doing into a seamless process.

From this perspective, it follows that synthesis, timing and balance are important:

  • Synthesis: Members work as one through collaboration and communication
  • Timing: Do the right thing at the right time
  • Balance: Do the right amount of each

These are the pillars on which MUDD stands and from which its principles are derived.

 

The MUDD Principles

Vision

As mentioned, working as one entity is an essential part of MUDD and for that to happen, you need a good vision, just like in any good marriage. It is primordial to have a solid, clear and the right vision right from the start. This does not mean that the vision cannot change along the way. The vision itself can be iterative and can evolve through time, but it will and should always stay true to some fundamentals. These are the fundamentals that you have to settle on and lock in.

A solid and clear vision helps keep the team and the product on track and consistent on two levels:

  • Conceptual level
    • the purpose of the product, what it does, its functions, components and features.
  • UX and Design level
    • the interaction layer between the user and the product, i.e. how the product works and behaves, how it looks and how it feels.

A combination of these 2 aspects of your product will help create and build its soul, with a consistent character, language and behaviour, which taken together form what some may regard as the brand of the product.

Having the right vision, on the other hand, will prevent you and your team from going down the wrong track and giving priority to the wrong things or making the wrong decisions down the road.

So MUDD recommends investing some time and effort (the right amount) upfront on establishing a vision. It will help to hold the team together, and keep things on track.

Whole team involved in one common task

In MUDD, the whole team not only works together during each development cycle, they work together and on the same thing. This is another way to force focus, improve cohesion and facilitate the solving of problems, especially between designers and developers. Doing this puts everyone in the same mindset and gets everyone involved in the problem being solved, or the solution being built. It also makes the environment more conducive for the emergence of feedback and insights, as everyone has the same problem in mind, and their minds are all within the same context.

As Ryan Singer, product designer and manager from Basecamp puts it:

“Integrating all roles around one piece of work allows everyone to keep the problem in context while feedback, pushback and new insights arise.”

 

Cross-disciplinary collaboration and communication

However, having everyone working together and on the same thing would be fruitless if there is no communication.

Good, rapid, frequent and efficient communication is essential because communication is essentially the flow and transfer of information, and if you want the team to work well together and work as one entity, information has to flow.

UX/Designers and Developers should, therefore, collaborate and communicate closely, not only during “formal” meetups such as:

  • Quick design workshops
  • Product/Feature walkthroughs, demos or reviews
  • Internal validations/usability tests
  • etc.

but also through quick, informal and ad-hoc discussions, such as over-the-shoulder feedback and guidance, popping-over-the-desk requests, etc.

As Roger Belveal from Trend Micro states:

“What this means is that an hour huddled at the white board and some over the shoulder guidance can accomplish a week’s work in an afternoon. It requires a super commitment to collaborative teamwork.”

According to Conway’s law, the design of a product is a reflection of the communication structures of the organisation who built it. It is based on the reasoning that:

“In order for two separate modules to interface correctly, the designers and implementers of each module must communicate with each other.”

Therefore, it follows that (and this might seem very obvious and simple, but it’s true) good software requires good collaboration, and good collaboration requires good communication.

 

Cross-disciplinary literacy and activity (XDLA)

Cross-disciplinary literacy refers to learning about the other’s discipline, while cross-disciplinary activity refers to performing a task which would normally be done by the other discipline. Done together, XDLA allows for tighter integration and flow between UX/Design and Development activities.

The more literate each member is in the other’s discipline, the faster and smoother the flow of information and progress becomes; actually doing the other’s task literally erases the dividing line between the two disciplines (which is more reminiscent of the phase-driven waterfall model, where one member hands over the job over to the next person in line), and synthesises the performance of two entities into one single fluid flow.

So what we are really trying to achieve here is something like this:

Where instead of having a clear separation between UX/Design and Development, we try to blur the line in between and synthesise the two.

Even though this applies to all roles and members within the team, it’s particularly important and true for the relationship between UX/Design and Developer, because these are the two roles that are thinking and doing respectively.

Specifically, XLDA involves getting the UX/Designer to learn about coding, the concepts of programming, or Agile/Scrum development, and conversely getting the developer to get some basic UX training, to learn about the UX practice, etc. Once they’ve learned about each other’s activity, they can then slowly start putting what they have learned into practice.

This will lead to examples like this, where the developer would be able to come up (after discussion and collaboration with the UX/Designer if needs be) with the design of a screen autonomously:

 

 

This is a very “simple” screen, and the point here is not about showing a fantastically designed screen done by a developer, but it’s about the latter having been able to use his knowledge of UX/Design coupled with an available and existing conceptual framework, to solve a problem and design a solution.

Two ingredients were necessary here for this to happen:

  1. The developer being UX/Design literate of course, as just mentioned,
  2. but also an established behaviour and language of our product, in the form of either a conceptual framework (or a visual style guide).

In the example shown, it was more of a conceptual framework and pattern, which we called a “Grid”. We already had a screen called the Attendees screen where we list down all the attendees who registered for an event. That screen is a very important screen of our app and was the one that was used as the base from which a pattern was created. It turned out to be a good and solid enough conceptual framework to follow and to use for different cases, including the Promotional Codes screen we just saw, as well as others.

 

The Attendees screen:

 

This is a very good example of a synthesis of UX/Design and Development. Individually, it was very unlikely that we would have arrived to this solution (at least I know I wouldn’t have, simply because for me, somehow, showing promotional codes has nothing to do at all with listing down attendees). But combining a conceptual framework provided by UX/Design, together with the expertise, skill and perspective of the developer made it possible.

 

Design comes first

As illustrated by the previous principle, the MUDD philosophy believes that UX/Design always comes first to guide Development. But not Big Design Up Front, where the whole spectrum of screens and interactions of the product are designed in detail and perfected before any development is even started. Only Just Enough Design Up Front (JEDUF). In the MUDD model, UX and Design is what drives the conversation at the start. We put design first, in every sense of the term, because remember: design is thinking, and the developer has got other stuff to think about on his side. You don’t want him to have to think about where is the best place to fit this particular button or that particular field, but you want to guide him on the visual and UX aspect and allow him to think about other things on his side.

The important thing here is the Just-Enough philosophy where you remove waste and have no excess or unnecessary elements. On both sides (i.e. UX/Design and Development), only produce just enough in order to convey the message that you want to convey. However, Just-Enough does not mean low-fidelity.

So some examples of designs done up front could be as hi-fi as these (for totally new features):

 

Or as lo-fi as these:

 

Or anything in-between for that matter.

But of course, in order to be able to pass lo-fi designs to the developer, you need to have created a conceptual and visual framework beforehand for them to follow. And that’s where you need to have the essential elements designed upfront. As Charles Krietzberg puts it:

“Limit up-front design to the elements essential for creating a holistic experience and do the remaining design iteratively.”

These are what some have called Essential Designs Up Front.

Essential Designs Up Front are the design styles and patterns (visual and/or conceptual) that lay the foundation for the rest of the designs that will emerge down the road. They are guides and “building blocks” that will enable the developer as well as the designer him/herself to derive new designs when required. The essential designs done up front do not have to be complete, but they must give a complete and holistic idea of the product.

The purpose of this is two-fold:

  1. To enable developers and designers maintain UI and UX consistency
  2. To allow for ways for the product to grow and extend gracefully

Think of it as a tool set and a scaffolding foundation on which others will be able to build.

As an example, some of the essential elements that we designed upfront included the following:

 

 

 

The need for a UX Owner

Through our experience, we have come to realise that there is a missing role in the scrum team, and that is the role of a UX Owner (UXO). Very simply put, if the Product Owner (PO) is responsible for making sure that the vision is adhered to from a business perspective, the UXO is the one responsible for making sure that the product is going in the right and consistent direction from the UX perspective.

Both of them have the product at their centre of their attention, but looking at it from two different perspectives.

However, on a deeper level and together with the PO, the UXO also checks on how the product is evolving and makes sure that the product is also going in the right direction in terms of its purpose and meaning. There is a reason why the product exists and that reason should always be valid, and whatever action is decided should always be faithful to that reason.

The UXO has a more hands-on role and is responsible for keeping UX in constant focus throughout the product lifecycle.

As Roger Belveal from Trend Micro states:

“Having a persistent presence on the team by a UX designer who has lead authority is even more important than having a finished design ready to code. Many detailed design decisions can be worked out in real time during scrum if there is a good rapport and collaboration and the designer has a vision for the product.”

 

Synchronising Thinking and Doing

Finally, the last principle of MUDD is about synchronising the Thinking and the Doing, and to explain this one, we will describe the MUDD process.

 

The MUDD Process

On a high level, we’ve found that what we’ve been doing is something like this:

 

 

We have a Big Idea phase (also referred to as Phase -1, Inception Phase sometimes) at the very beginning where the vision and the essential theme of the product is formed and determined. By the end of that phase, you will know what you are going to build, for who, and why.

Subsequent to this, we have a Phase 0 which is, generally speaking, a preparation phase where immediate items are prepared for Sprint 1, but also where “foundation frameworks” are created and set up, both in terms of development and design. From the UX/Design perspective, this is when the Essential Designs Up Front are worked on.

On a more detailed level and looking more specifically at Phase 0 and onwards, our process looks something like this:

This is very much similar to the popular “staggered sprints” by Desirée Sy from Autodesk, with the exception that:

we have catered for a third track for visual design.
  1. we try, as much as possible, to test and review the implemented stories within and throughout the same sprint, as and when these are ready.

Roughly, the process is as follows:

Phase 0

  • As mentioned, Phase 0 is for preparation. It is used to prepare both immediate items for Sprint 1 as well as “foundation framework” items (both for UX/Design and Development) which will serve as guides for future designs and stories downstream.
  • UX and Design work on and design the items required for Sprint 1.
  • It is ideal to have visual design and styles settled on by end of this phase. However, if that’s not possible, it should not prevent development from starting during the scheduled Sprint 1. Nowadays, there are many frameworks out there like Bootstrap which provide a quick way of getting something up without the final design applied. So development can start Sprint 1 by implementing any of these frameworks (which framework to use would have been decided during Phase 0 itself), while Design continues working on the visuals (during Sprint 1).

Sprint 1

  • Development works on Sprint 1 items.
  • UX and Designer work on and design items required for Sprint 2.
  • Throughout the sprint, the team collaborates closely and meet up for discussions whenever required and necessary; feedback is given as quickly and as often as possible.
  • Throughout the sprint, whenever tasks and stories are done, UX and Design (as well as PO) would check, review and test whatever is ready.
  • A bigger review is done at the end of the sprint.
  • Any updates or amendments required are carried over to the next sprint (or later).

The cycle repeats for the subsequent sprints.

Now this looks like a graceful and fluid choreography, where Thinking and Doing, and Development and UX/Design are all in sync and are moving forward together smoothly. In reality, things are rarely that neat. Like us, as you will realise, or as you might already know, things are very different in theory and in practice. So be ready to adapt and customise whatever model you choose to adopt to suit your own unique needs and situation. Don’t confuse theory with practice and most importantly, don’t take it as a golden and inflexible rule that will bog you down and hinder your actions.

 

Final Thoughts

Interestingly enough, over at GEVME, we are currently going through an important transitional phase, with plans of making some changes in terms of the engineering of our product, our team structure, our processes, etc. in order to bring our product to the next level. As a result, MUDD itself will also keep evolving with the changes happening in its environment.

With that in mind, I would like to invite you to appreciate the fact that the emergence and evolution of Agile (and now trying to combine UX with it) is really a representation, reflection and reaction to some of the big paradigms that our society as a whole has been going through during the last few decades, mainly as a result of new and evolving technologies.

Some of the changes in paradigms and their signs are:

  • Democratisation and the decentralisation of information and power
  • From vertical and firmly structured to horizontal and diffused
  • Ideas and solutions are emergent, i.e. from the bottom up, instead of being dictated, i.e. top down
  • Co-operation and self-organisation instead of authoritarianism

Actually, these are all concepts from the theory of complexity and Complexity Science.

In fact, according to Uhl-Bien, Marion and McKelvey (2007), our ways of working, processes and management structures in the Knowledge Era have evolved and have increased in complexity as a result of the growing complexity going through our societal structures at large. They posit that this is because in order for a system to stay fit and remain effective, it has to evolve and increase its complexity level to match that of its environment. McKelvey & Boisot (2003) (quoted in Uhl-Bien, Marion and McKelvey (2007)) call this the Law of Requisite Complexity and state that:

“It takes complexity to defeat complexity – a system must possess complexity equal to that of its environment in order to function effectively.

Requisite complexity enhances a system’s capacity to search for solutions to challenges and to innovate (…). That is, it optimises a system’s capacity for learning, creativity and adaptability.”

And there is no better way to illustrate this increase in complexity than by looking at the evolution of:

The linear, 1-dimensional and sequential process of the Waterfall model:

 

To the iterative, distributed, cyclic and self-organised system of the Scrum framework:

 

So knowledge workers, let’s keep the evolution going!

And as Zollers puts it, “The most successful teams have a custom agile implementation”. So don’t look for the perfect model, process or framework.

Instead, adopt, adapt, and create your own.

Latest comments

  • Great blog. Very insightful

  • Hi Cher,

    You are more than welcome. 🙂
    Do let us know if there’s a topic that you want us to touch on!

  • Thanks Jonathan for sharing your experience and approach on UX/Design & Development, and this is fabulously amazing!

leave a comment