Integrating UX in your project

There are multiple good reasons for using User Experience Design in your projects. I’ve already mentioned some in previous posts and probably in future posts. But the question remains how to use it in your project. I don’t think I’ll be able to explain all the details cause such integration requires time and experience, but here I’ll give some basics about it.

When you’re looking at project development according ALM you have three stages. Business, Development and Operations.
In the business stage you’re starting the project with initial contact, feasibility study, requirements, etc. Next is the development stage where you’re actually building the application. When this is done and released you’re going to support the application in the operations stage. When it’s time to stop using the application, you can end it’s life or you can go back to the business stage to update / rebuild the application according to new specs.

For each of these three stages I will show the additional parts that are involved. In the diagrams these parts are shown as the blue blocks.

You’ll start in the Business stage. Here will be the very first and I think the most important involvement of User Experience Design.



Business StepsUsually in the project you will start with collecting the requirements, define the functionality through usecases, set an application architecture and then step into the development stage.

The difference now is that after you collect the requirements you also visualize the suggested functionality through wireframes. This way you have a much better way to communicate with the customer and later on, with developers.

Next these wireframes will be extended in an interface and interaction design where screen functionality is determined. The usecases with the interface and interaction design is a very good documented base for stepping into development.

But before we do so, we first want to make sure that the functionality defined with this usecases, and visualized with the interface model, will actually work for the real users. To test this you’re going to prototype the individual usecases. Don’t make this too complicated. Make simple screens based upon the wireframes. Test these prototypes with a couple of users and without helping them. See if they are able to walk through the usecase. When stumbled upon difficulties or problems, go into your iteration cycle and restart at the usecase step.

If you have perfected the designs, then you’re setting up the application architecture. Define the framework and create the development environment.

Next step is development.



Development Steps There are several ways of doing your application development with the integration of UXD. First you have the serial way, like the ladder or waterfall method. But I prefer the parallel way with a possibility for the piggy bag method where design works ”in service of” development or visa versa.

In the parallel way you simultaneously work on the front and backend of the application in an iterative way.

But before you do this you first have to make an agreement between these two lines. This is done with two items.
First a wireframe in the development environment which developers and designers use for building their part.
And secondly you use something like a naming convention in which you determine how your frontend and your backend communicate. This can be through the definition of an interface model, writing down the element names that must be accessible from code, or another low-level way for linking design and code.

This is an iterative setup and likely to be changed during the development process. But this “naming convention” helps your team work simultaneously without depending on each other. Updates in this naming convention must be reported and thereby changed in the other line.

The integration is a separate step because it is unlikely that it will merge without some extra work. This is done after every development cycle which may be after the completion of an individual usecase.

If the application is ready (and tested and accepted) it will be published and installed. After that operations take over for training and support.



Operation Steps The main difference when integrating UXD in the project, that at the time you enter the operations stage, you are having good documentation about the interface. This will come in handy when you’re going back to the business stage.

You have the opportunity to re-use this documentation and define what changes are needed, or what didn’t work well in the application. This will allow you to give visual feedback to redefine requirements.

If you also have User Experience Specialists available, it is possible to test certain functionality and supply new information about the usage of the application. This too will be used to redefine the requirements once your back in the business stage of your ALM circle.


As you could have read in my previous post, there aren’t standardized User Experience roles and methodologies yet. What I just described is something we (Inter Access) are using in our development methodology, based on personal experience and what we’ve learned from how others (like Microsoft) handle User Experience Design.

I hope this will give some insight in how to implement UXD inside a project.

You may also like...

2 Responses

  1. In the Business Workflow, can you further illustrate the user type of the Prototype Tester?

    How should this process work in terms of functional testing? Do you just drop out a few Views and say, “Perform action …”… to see if their control response is trivial?

    Or, do should we actually build a mock-application with the views that actually work together (with a controller stub)?

  2. @Todd

    Very good point Todd. When it comes to prototyping, or functionality testing, you must try to keep it simple. Make it too complicated and you lose too much time. Also test per usecase. So if you have 13 of them, you probably will run 13 tests per user.

    The best way for a prototype is a visual wireframe with static dummy data, where the navigation part only works for the functionality that’s tested. So when testing, the user can walk through the different screens that belongs to the case.

    Before testing you write down the target that the user achieve. Like “start the batch processing”, or “verify the balance change”. Say nothing during the test, but let the user talk about what he/she thinks. Write down their thoughts, compare them with other results and make a conclusion.

    If you (like we) build the prototype in the language you’re probably going to use when in development (Like WPF of HTML) you can re-use parts of the prototype for the application wireframe. This will speed-up development for a bit.

    Maybe I will make a specific post about prototyping. There is absolutely more to it.

Leave a Reply

Your email address will not be published. Required fields are marked *