Enterprise Application Design Approach Question

23 Feb 2011 - 6:03pm
3 years ago
9 replies
1460 reads
R Sloan


Has anyone ever designed an enterprise application's first release to have only a wizard for creating complex 'objects'; then, offered a more hands on solution for a hot fix or subsequent releases?

The above question occurred to me during a presentation of an enterprise application that took months to design.  Moreover, it was only after the project had been developed could the design fully be realized in all of its complexity.

Fortunately, before the release, the designer was able to test the application and update the experience before the release.

Looking back on the process, they now realize that the complexity that became second nature to them over the months where mind boggling to the first time highly technical user.  Moreover, per these types of presentations / critiques, internal team members who had not worked on the problem where equally amazed.

From my perspective, part of the design's catch is that the designer must consider that these user 'pride' themselves on knowing and understanding these complex task and tools.

After the presentation, I had a discussion with the designer and had a thought / question, again, has anyone ever design the first release of an enterprise application where a wizard was the only way to create 'objects' for the first release, then, offered a more hands on solution for a hot fix or subsequent releases?



23 Feb 2011 - 6:36pm

Hello Sloan,

I'm curious about what you mean by "more hands on approach." I work on a large piece of enterprise IT for Microsoft, and we definitely consider ways to streamline the process even if it's already been established in released software. In the end, expert users can relearn a system, but the novice user experience needs to be such that there's not a ridiculous training cost associated with a product.

23 Feb 2011 - 8:31pm
R Sloan

The meaning of "...more hands on approach..." in this context is the exposing the full breathe and depth of the products, i.e. showing most or all of the widgets.

Basically, I have seen product after product grow in this fashion:

   1. Create the 1.0 release with minimum functionality based on time and money
   2. Add more functionality and move more towards the desired vision
   3. Make the product 'feature rich' / ‘complex featured problems’
   4. Use a wizard based approach to simplify the task and 'get the users up and running'

I am thinking / ask if anyone in the enterprise application space ever developed a product in the follow manne, i.e. turned the procedure on its head, a la...

   1. Create the 1.0 release with a simplified task based wizard to 'get the users up and running'
   2. Add more functionality and move towards the desired product vision
   3. Make the product 'feature rich'

23 Feb 2011 - 8:32pm
R Sloan
25 Feb 2011 - 9:02am

That is an interesting question. After 15 years of enterprise design experience here is my thought.

As part of the strategy of beginning the design of an enterprise application or a module in a suite of application I have positioned the question around should we create an application with more user assistance or "training wheels" whether that be a wizard or some other technique. Or do we design an application assuming that theuser will receive training and be brought up to speed.

This has always resulted in punting the user assistance for "time to market" of the application. So the answer to your question is no not when asked explicitly.

What I have found now in the agile world is that I do not ask those questions. I design a simplified experience with assumption that we will learn better what the users want as we go along. A wizard is not always more simple but that needs to be hashed out through sketching and doing comparisons of options before you can determine the best design to meet the simplified experience and features in the product.

So I advocate for not posing the question as opposites but to change the process by which you get the team to approach the design. Know where you are going but design for now which should have minimum features and simple designs until you learn more. As the product grows and you add more workflows things will have to change.

27 Feb 2011 - 11:32pm
R Sloan

Thank you for answering the question directly.

I have also taken a progressive disclosure approach to complex task as a part of a 'training wheel' effort that have been partially implemented or punted all together with only some level of success in the end.

Moreover, in the agile environment, I find that it is more important to have more understand of the task, the user, and the design to make sure that as Development begin any iteration they know 'end goal.'  In other words, user experience processes are just as relevant and important for creating a 'whole' design through agile's iterative design process and Development implementation.

So it was not a question of one or the other; it was a question of whether someone has been able to implement an enterprise application design that guided beginning users in the first release of a product to understand the level of success.


25 Feb 2011 - 9:23am
Dave Malouf

Apparently I added my comment to the wrong thread. 8-)


Short answer is yes & no.

The long answer is I designed it, but it never got off the ground, b/c the dev/marketing team didn't think it would fly.

It seems to me that you had a research problem, as well as a ramp up problem that is not necessarily reliant on the level of complexity of the tool. Did you design the "out of the box" experience so that the level of complexity can be introduced to your primary stakeholders in a way that they can grasp that complexity? Or Did your designer/product team do enough research of the intended user set to better understand their mental models so that the complexity (of which they are probably most expert in given your experience) was modelled in such a way that they can map the application to the application's intent w/ minimal issues?

Probably the combination of these 2 issues could lead to a better experience.

Now, why in my case did I do it 1 way then release it another. It was actually b/c the research came back and determined that the simple version would not have sold. It would have been seen as not powerful, which at the time was "off-brand" and we went back and designed a ramp-up program that achieved the requirement based on that same research, but still gave end-users the tools that made them feel comfortable and allowed them to succeed in their work right away.

A tool that helps this is "progressive disclosure". It hides the complexity only presenting it when the user requests or requires it to achieve their goals.

-- dave

28 Feb 2011 - 12:06am
R Sloan

For this highly technical audience, the general expectation in the past has been 'give them access to all and they will figure it out because they want to figure it out'.  And this is part of the dilemma, the expectation's placed on the users by their client and their 'persona', i.e. I think what I am, trying to state is 'how do you give a user, who does normally want help, help with a complex new task?'

Again, the out of the box experience for this set of user gives them access to the broad range of the products feature, as far as I could discern, which is typical.  And the only thing I could see that the 'general' research never really covers was how external factors, e.g. time to load a screen or other external tools used in tandem, affect the product's use.  However, your point is well taken.

For this audience, I again confirmed over dinner last night with a user, they 'like there products flat' and they 'don't like to dig for it.'

Thank you for providing a personal example.  It's interesting but I can understand how the audience could perceive the product in that light.  What is amazing though is that it appears that people would like struggle somewhat to be 'powerful'.

Thanks again,

25 Feb 2011 - 5:52pm

The problem with designing simple and wizard-like feel in version 1.0 is that you will always find users who have corner cases and requirements which eventually will make the system even more complex.  And if you don't have the basic foundation of the design correct in your first version, you will likely find that in version 2.0 you are going to have to do a major re-design of the application anyway. 

I guess what I am saying is, it's not the complexity that you should worry about, it's more of how you design progressively.  Can you really say, "hey let's make things simple in our first release, and wait and see how users respond" and then change the design altogether for a better experience in the next release?  Requirements will always get more complex, and at the end you might be piecemeal-ing your design as oppose to design for a better user experience.

28 Feb 2011 - 12:21am
R Sloan

I did not mean to state or imply that the first release would exclude the more technical functionality OR that the design (not implementation) did not look beyond the first release for definition -- typically, I have created designs that are implemented over several releases. 

I did mean that the wizard would help the user to define the 'basic' elements of the 'object' then let them define the details afterwards. 

And the question to the IXDA audience was has anyone implemented the first release of a major feature / product that helped the user to define the 'basic' elements of the object in a flow, then allowed them to define the details via discreet interactions?  If so, how successful was this product and how did you overcome the internal challenges to 'get the product to market'?

Syndicate content Get the feed