Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

In a software development process where does the user interface design fit?

If we take an agile approach for a small team (2 juniors, 2 seniors, a Team Leader and a web designer) what normally should be done is:

  1. A list of requirements is generated with the customer.
  2. A list of features in extracted from the use requirements and for each requirement a list of scenarios is written.
  3. Each scenario is translated into an acceptance test and development starts using TDD.

In this team developers do both the front and back-end development.

Till now we didn't give user interface design much value and most of the time we built very simple mock ups to ourselves that are given to the web designers to implement. Sometimes the user interface is built before the feature is implemented and sometimes after it.

Currently we want to give the user interface design more attention and to involve our customers in the process, but we don't know how and when should we do the user interface and how can the user interface affect the requirements.

share|improve this question
add comment

9 Answers

up vote 2 down vote accepted

Disclaimer
As our field is still rather young, many of the terms we use are not stabilized enough for a discussion as generic as this one to converge.
Additionally, stabilized terms are regarded as outdated, like "usability", and are avoided in order to be modern.
I'm pretty sure that many of the answers here (I like all of them!) are referring to somehow different things using the same words, so I'm going to try to avoid all such words except "usability" which hasn't been mentioned until now.

In a software development process where does the user interface design fit?
Well, everywhere is an answer. Unless if by "user interface design" we mean the work of the graphics designer, then it fits ... where?

What is meant by "software development"?
Given the size of Songo's team, one can guess that they are working for a rather small web site or web application.
The size matters, and it matters a lot.
Most applications can be defined by a small set of wireframes (say, 10 or 20). The way the interaction contexts (ICs, screen or dialogs usually, but also physical button panels or whatever a user can use to communicate with the system) interact among them can be guessed, or be explicitly stated, in such wireframe set.
The wireframes serve as a complete software specification.

Instead, if the app was comprised of thousands of ICs then we would need another artifact to describe interaction.

In both instances the interaction between the ICs is the most significant part in the attempt to achieve usability, allowing the users to do whatever with efficacy, efficiency and satisfaction (as per the ISO/IEC's definition of usability).
How come? Yes, first we need the users to blaze through a path of interactions straight to their goal through our UI without losing the flow state of their minds.

So in order to answer what kind of a development process is the right one, some of these variables should be tethered.
Like, size of the applicaqtion, its complexity, the complexity of the domain, number of developers working on it, there must be more.

Anyway, everything has to be done
Things start with a requirement from a stakeholder (somebody with a vested interest in the app). This is not an instance of software requirements, this is at most a business requirement.

What comes next is some field research.
Interviews with users or with personas.
Many times small teams working on a permanent fashion for a stabilized application don't feel the urge to go out to try to figure out the reaction of their users to what they are going to implement, and they might be right, so the field research does not show in their radar but some how it has to be done, at least imagining one of their users using the new UI and figuring out (based on a long experience) how it will fit.

The knowledge about the users and their reaction to the new parts is used to imagine how would they use the new UIs. Ideally one would put the personas to operate it and try to find out if Joe Sixpack will be able to go trough it or not.
In this stage it's ideal to stay as abstract as possible. Functional analysts can do it, describing a user operating the UI without drawing it. Other people are more graphic and want to start drawing ASAP. Resisting this urge leads to better UIs, faster development and higher usability. In short, it's because once you go concrete you get trapped in concrete and the odds of trashing a design get too low. Being abstract lets you move freely between alternatives, like a butterfly in a garder full of flowers.
On the other hand, chances are that if you drew a high-fidelity mockup, chances are that you end up stuck with it, even if it was a crude firat idea, and that you start loving it. And if the manager saw it, then it's frozen.

Albeit being abstract, this part is a substantial component of the design of the UI and the way it works.

Over time (one hour or one month, it depends) the imagined and may be written descriptions of users using the UI (which I call "scenarios") get stabilized by intelligent consensus.
In a series of brainstorming sessions the team can write a list of what actions will the users need to perform to use the system in order to fulfill their goals.
A list of all the things the users will be able to do, like the app's menu, will be produced, and if the list consists of a single item or two then don't do it formally because it's implicit.
Now it's time to write down (still not draw, sorry) the description of how it works, in terms of the dialog of the users and the system. For each of those goals a list of the steps needed to successfully go from start to end is written.
After doing that for most of the interaction tracks the team brainstorms most of the things that might fail, like in a login interaction that the password doesn't match.
Only the pitfalls that the system can manage are to be listed. For example an aerolite devastating the data center is out of scope.
Next you add interaction steps to handle the issues listed, and you have the core of a nice set of use cases.
These are informal, textual, rather structured, as-simple-as-possible documents.
By having brainstormed and decided how to handle all those conditions in advance you now have a rock-solid specification for the developers.
And, whether you like it or not, you have made substantial definitions about the behavior of your UI (thought you still don't know how will it look like).
But handle those UCs to the testing people and they will love you.
The developers will also love you, instead of calling you at 3AM to ask what to do if some condition happens.
All in all, the result will be better bur achieved with greater ease.
Before handling the UCs to the developers you should satisfy your graphical abstinence by doing two things, or three:

1- do a controls gallery
2- draw wireframes
3- define styles

The controls gallery thing is a definition about how to show each data piece, like an international address, or a phone number: how to label it, how to enter the value(s), what validations to do.

We always do it all
The funny thing with all these steps is that we always perform them, either consciously or not.
Either in the right order or not.
Many times we skip a step only to have to perform it later, at a much higher cost (in terms of effort) and achieving an inferior result.

All these steps lead to a UI that will work fine and that will look reasonable. Now you can give it the magic touch to make it excellent.

share|improve this answer
    
well +1 for the effort and time given to write such a detailed answer and +999 for the sound of experience :) –  Songo Mar 18 '13 at 12:21
    
@songo: thanks. Actually I can write about this very quickly (despite not being a native English writer) because I'm thinking about this since 1998 when I first worked for an internet site. I noticed that the things I was doing since the '70s had names, like "usability". Later on I thought a lot and the requirements thing came. Recently I was teaching about this to FAs of a big bank and it was a real success. –  Juan Lanus Mar 19 '13 at 13:02
add comment

Personally I don't see UX as being out of band with ALM. I also don't see UX as a single process only. In our projects it works like this in an agile environment:

  1. BA and UX team extract requirements from customer
  2. Group begins backlog story creation
    • BA creates functional stories in conjunction with UX
    • UX creates wireframes in conjunction with BA
  3. Group goes back for approval with customer
  4. Group grooms backlog with the wireframes becoming a story requirement
  5. Story goes into sprint
    • UX Design for story takes place
    • Development for story takes place
    • QA testing takes place
  6. Story is complete
    • UA acceptance take place

If you break the UX processes down into what actually takes place you are able to separate requirement gathering and development to where they fit nicely into ALM processes.

share|improve this answer
    
+1 great answer with much details. can I ask what your UX team consists of? and about the wireframes that the UX build, do they build them for all scenarios of the story? for example "As a user, I want to search for my customers by their first and last names." do you create wireframes for scenarios of results found , no results found and invalid search criteria? –  Songo Mar 11 '13 at 22:24
    
Yes they build them for all scenarios, many of which are reused from other similar areas. invalid search will pretty much look like other invalid searches. Errors, and no results are an experience and if it's a valid scenario, it should be represented and thought out before development begins. I always just think of it as part of the grooming process. –  Victoria French Mar 11 '13 at 22:36
    
I see, but what about your UX team? what are the roles of the people in that team? I'm asking because people on our team are mainly back end developers (PHP, ASP.Net) but we have good knowledge in javascript so when it's time to do front end stuff it's usually a collaborative work between a developer and our web/graphic designer (who knows Photoshop and CSS but no javascript). –  Songo Mar 11 '13 at 22:44
add comment

I'm currently involved in a large multi-team Agile development project where UX does play a significant part. What you're describing is a common problem in most development run projects where design is considered an after thought, a 'just make it pretty' approach to design.

It was a bit of a battle to introduce this change into the project because in my humble opinion Agile is not the ideal project methodology for proper UX delivery. Notice that I'm using the term User Experience, not just user interface design. Our current workflow involves the UXD to be involved in all the iteration planning meetings, starting from the initial scoping session. Once we have received the requirements and the initial story breakdown is done, the UXD takes the stories and estimates the required effort to come up with the solution, in most cases the estimate is divided by the story to make it more agile. Depending on the complexity of the requirement, this could be an entire iteration (or multiple iterations for that matter) or just a couple of days. This estimate is then included in the overall planning for the project. So in other words, you can consider a UX Sprint to be included prior to the actual dev being started.

Also, the UXD works very closely with the dev team to ensure iterative reviews once the development starts and in most cases there are a couple of iterations before the functionality goes to QA. Also, the QAs also work with the UXDs to ensure that the final sign-off involves a UX sign-off as well to be sure that the final solution that gets pushed to production is something that has been checked both from a technical point of view as well as a UX point of view.

share|improve this answer
add comment

It's not about the user interface. That is only a part of the User eXperience (UX), and may not be your biggest UX problem area.

A developer is no more the person that should be doing your UX and front end, that a designer should be doing your development. Many developers don't get this, but you need a good UX and design person (or people as they don't have to be the same person) on your team. You will end up with a better product, and (in my experience) a shorter development time.

I have had to learn the hard way, that you should start with the UX. Simply getting a list of features from a customer will always result in a list of everything that they ever wanted the application to do. You should push back on this and question every feature because if you were to implement every feature, your application would 99% of the time be terrible to use.

Example: Nokia 5800 (Symbian) vs. iPhone 3GS (iOS). Technically the Symbian had more features and was technically superior. But it had terrible UX which I am sure was designed by engineers and developers. So it was nowhere near as successful as the iPhone 3GS.

enter image description here

In the end your customers won't see how awesome the backend of your application is. They will judge it based on their experience interacting with it, and so that is what you should focus on at the start.

TL;DR: Get an experienced UX person in to do the UX first.

share|improve this answer
    
Oh dear John, you are back to your habit emphasizing every other phrase in your posts. I have noticed it growing back slowly for some time now. It really doesn't help you know. You and your answers are way too good to need a pounding fist on the table every few hundred characters... –  Marjan Venema Mar 11 '13 at 18:53
1  
@MarjanVenema Thanks for the compliment :p The goal is to make scanning better, but I will try keep an eye on it. Sometimes there are just too many points that just need emphasising. I'll take another look at this one. –  JohnGB Mar 11 '13 at 21:04
    
@JohnGB Thanks for the great answer :) a question though about " you need a good UX and design person (or people as they don't have to be the same person)" Do you mean a user experience expert and a user interface expert? How would a task be handled by them? one creates a wireframe and the other implements it? I thought implementing them was the job of the web designer! –  Songo Mar 11 '13 at 22:45
    
@Songo I meant that you need both good UX and good design. Many UX experts are also great designers, but the two tasks can easily be separated between two specialists. They would need to work closely together though. –  JohnGB Mar 12 '13 at 0:40
    
On the bold text front this question may be of interest ux.stackexchange.com/questions/28762/… ;-) –  adrianh Mar 13 '13 at 11:44
add comment

A lot of the answers here are stating UX has to happen prior to development. That's the antithesis of Agile, so likely aren't going to best meet your needs.

That said, there is some truth in that some level of UX needs to happen ahead of time. One way to handle this is to do UX in one iteration, dev in the next. That way UX is ahead a few iterations doing the high level UX work, but is also validating current UX work being developed in the current iteration.

This can be tricky, and is yet another thing to manage, but can work.

Another thing to consider is Lean UX, which was influenced by the Agile dev process:

http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/

share|improve this answer
add comment

UX is done alongside requirement specification as part of the requirements gathering process. Both processes require some similar activities - getting data from customers, speaking to stakeholders, running workshops and the like. Both attempt to discover problems to solve, before UX validates its assumptions with prototypes and user testing and the BAs validate their findings and start writing user stories.

This should all be going on in the iteration before development, even if you're not in a TDD shop that requires all the requirements to be bottomed out before developers begin.

share|improve this answer
add comment

Putting UX before development is the way to go. Small revisions will happen as the client uses the application, but the bulk of the UX will be done in the planning stage. It's much easier to change things on paper than to get developers to rewrite parts of the application at the last minute. Last minute direction changes hurt the quality of the code and the morale of the developers, and usually means extended deadlines.

share|improve this answer
1  
There's some truth to this, but at the same time, that's traditional waterfall, rather than agile. UX can't all be done sans code, just as all UX can't be done in code. So it's a tricky balance. –  DA01 Mar 11 '13 at 21:14
    
That doesn't mean it all needs to be done before coding. However, the cost will increase in proportion to the amount of code you've written already. UX changes usually impact the structure of the application, and as such should be planned as early as possible. –  Nicolas Bouliane Mar 12 '13 at 15:04
    
I agree...but also disagree...the thing with doing all UX up front is that you can also 'over-design' things which is what Agile is supposed to help remedy. In other words, doing all UX up front can be costly too. I don't have the solution yet. Still working on that balancing act myself to find the right mix. –  DA01 Mar 12 '13 at 15:17
    
Perhaps you will if you start thinking about the minute details, but I was mostly talking about major UX changes. These define the behavior of the application and will greatly impact any development effort. Button colors shouldn't get in the way of fast, agile development practices. –  Nicolas Bouliane Mar 12 '13 at 17:51
    
But that is also partially what Agile is designed to prevent to an extent. With waterfall, I completely agree with you. Changes to the UX during dev are a nightmare. Hence Agile, where the idea is you build piecemeal. This allows you to quickly build out functionality and validate it before continuing down the path of further development. In a way, it's bring UX processes into the development cycle. That said, I do see that that, in turn, also causes various pain points so yea, sorry...just rambling out loud now...(Still trying to formulate an answer...) –  DA01 Mar 12 '13 at 18:03
show 1 more comment

As most have pointed out, it sounds like you definitely need to consider bringing some ux skills into your team. Perhaps a ux consultant could work with your current web designer to impart some of the necessary skills and techniques required that they could then build on themselves. It's interesting that from my own experience, many software development companies see design as a glossy layer that can be placed over the top at the end. However, Interface Design alone is just not enough with the breadth of today's technology and devices to competently inform how an application should work. Users need to be considered every step of the way!

In terms of process, It's worth googling 'Agile UX.' There are some great articles out there that suggest different ways of tackling the tensions between developing applications in parallel with the design.

share|improve this answer
add comment

UI (or actually more: UX design) should be an initial phase, before the development starts. In some cases it is possible for some work to overlap, e.g. when you have the concept ready, all the flows estalished and based on this you can start planning things like database structure and forging functionalities to programmistic mechanisms.

You can refer to this diagram for more detailed information how the UX design goes from Conception to Completion: http://www.jjg.net/elements/pdf/elements.pdf

The other aspect of UX design is control - during production a lot of situations may occur that will involve both changes in UI design, flows and programming.

share|improve this answer
    
It's maybe just worth noting in reference to that elements diagram, that Jesse James Garrett almost immediately regretted using the vertical time arrow, because he did not mean to indicate any kind of rigorous time based process or waterfall type of method. –  Roger Attrill Mar 11 '13 at 19:19
    
I agree it's an ideallistic model (and not necessarily possible to follow). But in the same time it refers to some idea of pragmatic and consequential going step by step from concept to the outcome. The main problem in implementing it is the complexity of the project environment, which makes it necessary to adjust the process and method itself. –  Dominik Oslizlo Mar 11 '13 at 20:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.