Search results matching tag 'Application Lifecycle Management'

In Control

AvdMeulen — Tue, 10 Nov 2009 07:55:49 GMT

What I realize more and more is that the end-users wants to be In Control. This applies especially with new developed applications that automates some of their work. By default users are skeptic. The application have to earn their trust. The more they get the feeling they are not in control, the less trust and the less acceptance of your newly developed product.

Only when the product doesn’t automate or replace existing work, an employee is likely to accept the application more easily. But still you first have to prove it and earn the users trust.

So what can you conclude from this:

At the moment you are working on a project that will automate a part of the users work, try to learn how he does that work, and don’t take away his flexibility. It´s allright that the application makes decisions and perform actions that he normally did, but certainly in the first releases, let him be the one that controls the final action.

For example when it comes to communication with customers. Originally he had to write and send the emails by hand. A desired functionality of the application is to do this automatically. A good approach to fully reach this functionality is to split it in several releases.

In the first release make sure the user can see all the emails that are about to be send, let him edit the emails if he likes to, and let him push the button that finally sends the mail. The user can see what the application is doing, and will build some trust with it.

So in the second release you extend this functionality with a scheduler and a “do send” / “do not send” checker. The user have to “check” the emails for “do send” and they are send automatically on a configurable time. The user can see if the scheduler works and that the emails are send correctly. So the trust in the application increases more.

In a third release all the emails are set default to “do send”, and the scheduler sends them every half our (or something). The user doesn’t really have to look to the emails anymore, because he now trusts the functionality of the application. He still has the possibility to go and check the emails, alter them, deny them or disable / configure the scheduler.

If you do it this way, the user feels he is In Control. So the acceptance of the new product is much higher then if you fully automate the sending of email, but nobody had the ability to check or prevent what is being send.
Even if a system is flawless and everything is working exactly as designed, there will always be exceptions in the process. And if the users don’t feel they can do anything about it, they get the feeling they are not in control. It is very likely that your new application won’t be accepted.

Just make your users feel they are In Control!

Designers & Developers within the ALM / TFS vision.

AvdMeulen — Tue, 02 Jun 2009 10:17:54 GMT

What Wikipedia says about ALM:

Application lifecycle management (ALM) is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.

Like most people know, Microsoft supports this with their Team Foundation system.

This is very cool and keeps getting better and better. And with the introduction of Blend 3 (The tool for creating interfaces & prototypes in WPF or Silverlight) Microsoft is extending this towards application design. And this progress is where I have a special interest in.

TFS supports different roles within their ALM vision. Project Managers, Testers, Architects, Developers, etc… There have been very much attention towards specializing the tooling towards the specific needs of the roles within ALM. And now they’ve added Blend to this.

I am currently spending a lot of time trying to integrate User Experience Design in this ALM vision, with primarily using Microsoft technology. And yet I still haven’t figured out how exactly Blend fits in the process. I mean, it’s a really great tool, and I do like to work with it, but when you look at how it must fit within your development process, it’s hard to tell where to place it.

I know for a fact that a lot of Designers aren’t really enthusiastic about it. Why is that? Because you can’t really design in it. Microsoft knows this and that’s why they created the Photoshop and Illustrator import in Blend 3. I also know that Developers try to avoid using Blend, because they like to prevent a tool that will alter their code, markups or projects.

So that means to me that there are only two roles possibly using Blend. Interaction Designers and/or Integrators. And now I am wondering if this is actually part a of ALM. And does it need to be a part of it. How do you work together as designers and developers. And how do you do this with TFS, using Blend.

I’ve seen some great ideas, but every project so far (including projects within Microsoft) does it their own way. There is no real thought on how to work together.

Maybe it’s time to refine all these technologies, patterns and project guidance's and set up a good way for letting the User Experience part collaborate within the Application Lifecycle Management.

I’ll get back on this.

Integrating UX in your project

AvdMeulen — Wed, 04 Mar 2009 11:35:30 GMT

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

Usually 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

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.

Operations

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.

Why is User Experience Design important

AvdMeulen — Tue, 10 Feb 2009 12:36:25 GMT

This question is asked regularly, by management, sales, development, and other people that are often responsible for deciding if UX will actively be part of the project. And without someone who actually has some experience with it, this question might be difficult to be answered. And because it really is important, i will try to provide some answers.

The answers I provide will be based on projects using Application Lifecycle Management which basically means that you have three parts. The first is Business, where you define the requirements. The second is Development, where you build and test the application. And the third is Operations, where the application is used and supported. From the last you can go back to business and repeat the cycle, or you can end the use of the application (end-of-life).

Management

First an answer for the management. If you want to convince them for implementing UX in the project, they will have to see that it is a value-added asset. And this is why:

Improved requirements
If you want to use UX in your project, you must use this from the very early stage of your project. By adding Wireframes, Interface design, Interaction design, Rapid prototyping and User testing. You can better serve your client because now you can show him what can be expected. This is indeed an extra investment and extends the requirement period, but if you do this right, it will be worth it right when you enter the development stage. Development time will be decreased and with it the development cost, and it will bring you to the next reason.
Faster time-to-market
Because you have significant increased the quality of your documentation, the development time of the application will be decreased. You will experience less last-minute changes and unseen flaws. Your testing will be faster and better because of the improved documentation. With all this you can deliver your application much faster. In fact, if your project team gets more experienced of working this way, you will compensate the extra time you’ve invested in the requirement period.
Increased value per user
Once the application is deployed, the users of it will be able to work better, faster en with less mistakes because the interface is specifically designed to their needs and way of working. New employees will need less time to learn the application as a good user interface will explain itself. Thus overall you can see that the output per user increases with the implementation of a good User Experience Design.
Extended application life
The life of an application is also increased. Applications with no interface- and user experience design often end up to be replaced earlier than applications which have both designs. This because the application does not function as well as expected. Users will complain about this and therefore will ask for something that will work better. With enough complains, the application will be replaced. With a good UX the complains will be reduced to a minimum so it stays in business for a longer amount of time before a replacement is needed.

Development

Why is using UX better for development? First of all, you start development with a much better functional and technical design. You have less last-minute changes and unseen flaws, so the time needed for building will be decreased. I think every developer would very much like the idea that he doesn’t have to do things twice.

Ideality you would like to let the interface be build by someone who is a specialist in designing and implementing interfaces. When working with WPF / Silverlight, I often see three roles. A designer, a developer and the one who stands in between, who’s called an Integrator. I will tell more about these roles in future blog-posts.

It is proven that working this way in development, where you treat front- and backend separate, has resulted in better applications and happier people that were involved. That alone is a very good reason for using UX.

Customer

And the final part, why UX is better for the customer. Here are some reasons:

Visual feedback
The most important, i think, is the way how you communicate with your client. Because you not only will have text for describing his wishes, he can actually see what it will be once it’s finished. By drawing wireframes, making an interaction and interface design, prototyping suggested functionality, you allow him to get a far better impression then with text alone. And because of that, he also can see and explain why and where things needs to be changed. If you are prototyping, you can also test if his request works. Prototyping will also remove assumptions, which is always good when trying to work you way to a solution.
Increased value per user
As i explained in the management part above, the application will increase the productivity of your users. In the perfect world, you will actually build an application that will work for the user, instead of, what most users experience now, that they work for the system. When you achieve that kind of application, you will dramatically increase the amount of work a user can generate for the customer. But with a good UX, you can get pretty close.

I hope this provides some answers and a bit more insight in why User Experience Design actually is so important. Without it, the most impressive applications can fail in real live, because no-one knows how to use it.