16

Apologies for the long, quasi-confessional, but I am really feeling a bit lost here.

I am a domain expert and experienced programmer. For the last four years, I've managed the development of a successful, very specific business-to-business webapp that has enthusiastic users and is growing quickly.

At this critical point, I feel the single most important issue is to improve the user experience. I have sat with users over the last four years and can tell you exactly what is confusing to them, what makes no sense, and what were simply poor design decisions on our part.

Every time I look at our cookie-cutter UI (built with javascript components clearly inspired by Java Swing) I cringe, and cringe again when I hear users joke that the app was "clearly designed by programmers." (It was)

As we begin our redesign, I want an app that is logical, intuitive, and beautiful. I want to retire our video course and just point folks to the app, which will be so self-explanatory that they won't need to switch contexts to a help site.

I have hired a freelance "UX designer" who has been extremely, extremely helpful in fixing and re-imaging critical parts our mental model, if for no other reason that he has been assertive enough to successfully challenge my own strongly-held ideas about our app.

But as we try to move towards actual HTML/CSS that my team of (basically color-blind developers) and I can actually use, I'm feeling a bit lost. I've asked the UX designer to put our high-level conversations into an HTML layout and it's crap. He's shown no interest in looking at the extensive sample data I've shared, and has come up with something that is both ugly and doesn't really cover the range of use-cases that we face.

He's suggested that I do the wireframes myself because "I understand all the details" and find a designer who can do the HTML/CSS design.

Bah, so I'm back to square one.

I'm confident in my domain expertise, but as a programmer, I've only ever worked in teams of programmers. (My first job was developing a set of computational geometry routines!)

How do you divide responsibilities and deliverable between

  • domain expert who knows requirements
  • ux guy who knows how users think (or something)
  • designers who can express things visually?
  • programmers who need the html markup/css spoon-fed to them because we are color blind, tone-deaf, and prefer command lines anyway.

How do "proper" software companies work?

Please help!

  • 1
    I have one question before being able to answer: what did the UX designer actually provide? Did he produce some wireframes? Did he write some user scenarios? Did he design a Photoshop layout? It's critical to know that in order to tell what you actually need right now. – jgthms Feb 7 '14 at 21:02
  • To date, the most valuable contribution of the UX designer (very valuable) was to help us to better articulate the webapp's "mental model." One example: in our current version, users create their own "databases" and then can create groups within those "databases". He helped us understand that "database" is too loaded as a term, and that a distinction between databases and groups was unnecessary. Presenting the whole thing to the user as a set of nested folders eliminates much confusion. I asked for HTML mockups that I could give my developer, but they're not good. – ProgrammerYearningToBePretty Feb 7 '14 at 22:37
  • 2
    Ok I see. Approaching a UX designer is actually a good approach. Most developers would rather look for a UI designer to make things look pretty. You went the more in-depth path, so I don't think you're back to square one (as you mentioned). – jgthms Feb 7 '14 at 23:48
8

Hiring a UX designer is great first move: you focus on the user aspect, on his needs, on his behavior, on his expectations, as a website user, and not merely as a website viewer. That's a good decision. You're definitely not back to square one.

The UX designer showed you that you need to introduce a level of abstraction in your interface. Users don't care about databases or about how the data is represented in your backend. They care about what the data means to them, what it represents in their own mind.

This abstraction is conveyed through words, through concepts, but mainly through your interface. At this point, the UX designer should be able to provide you with rough mockups of what each page of your app should contain, and explain what the general flow should be. He should describe some typical user scenarios: user comes here, he wants to do this, so he clicks here, he arrives on this page where these fields are shown in a particular order, the user performs some actions, he has achieved his objective. (It's hard for me to give you examples because I don't know what your app does).

The Front-End Developer is the person you need to transform these mockups in functional HTML/CSS templates. It doesn't have to be pretty. It just needs to work, to come alive. It's basically positioning elements and be decent looking. Bootstrap is the perfect tool for this: it's easy to use, and it visually makes sense.

The UI Designer is the last step of the process. He's here to make things look pretty, to give a visual identity to your app. Check out Dribbble if you want some examples. But it's not really that necessary at first. It might please your users for a while, but in the long run, the UX part and the Front-End part should be your priority.

I'm not sure I've been exactly able to answer your question, so feel free to ask me some as well.

  • This is very helpful! Now that you describe it, involving the UI Designer later in the process makes a lot of sense. The one part I'm still unsure of is the detailed UI design: for example there is one step where users need to import a spreadsheet and specify what each column contains, and based on this, match values in those columns to existing rocords or create new ones. We have a high-level wireframe, but when I actually build it looks cluttered, I've obviously added too many buttons/checkboxes, yuck. Is this type of thing the work of a (good) front end designer, the UX designer, or...? – ProgrammerYearningToBePretty Feb 8 '14 at 10:22
  • 1
    It's difficult to actually make clear distinctions between all these terms. UX Designer, UI Designer, Front End Designer, Web Designer, Front End Developer, Graphic Designer... Think of all of these terms as Venn diagrams that overlap in many different ways. I myself do graphic design (Photoshop, Illustrator...), write HTML/CSS, do some jQuery, and have some UX skills... Web designers do either one of them, some of them, or all of them at different levels. It's never really clear for us either. – jgthms Feb 8 '14 at 12:41
  • About the spreadsheet import feature: what does your high-level wireframe show? A layout? A process? Does your interface in the end look cluttered because of the actual HTML/CSS code, or because the wireframe isn't precise enough? – jgthms Feb 8 '14 at 12:45
  • Thanks again for your insight. Moving from the wire frames to real code, a few things happened: (1) scale changes: in the wireframe text and lists fit nicely in the rectangles. When populated with real data at actual screen resolutions, it's a mess. (Some) users have supplied novels for their input instead of the nice four-word phrases we used in the wireframes. And the wireframes don't cover every scenario. Example: the user indicates that column 3 references "Part Number". How do we deal with mismatches? What if it's a new part number and the user is authorized to add parts? – ProgrammerYearningToBePretty Feb 8 '14 at 19:56
  • 1
    Just saw this on GitHub: github.com/Snugug/north#roles-and-responsibilities This section can definitely help you as well. – jgthms Feb 17 '14 at 23:37
1

Generally at this point in the evolution of UX, the analysis/user-research/design/UX/front-end code is best handled all by the same person or team. Although it's always difficult to know what's really going on in a specific scenario, if your UX guy is suggesting that other people do the wireframes and HTML/CSS, I think you need to find someone else.

  • Hmm I don't know if that's totally true. There are people who get PEOPLE but aren't artists and aren't programmers. I mean they should be capable of making a wireframe I'd think, but theoretically speaking that doesn't mean they aren't useful. – VoronoiPotato Feb 7 '14 at 21:04
  • For sure that may be the case, but they would still be part of the User Experience team as I specified in my answer. – grover5 Feb 7 '14 at 21:13
  • your closing statement contradicts that (i'm not the downvoter) – VoronoiPotato Feb 7 '14 at 21:16
  • I agree, User Experience is always connected to the Interface and should be handled by the same person/team. HTML/CSS is not THAT complicated and every person who works with (web-)interfaces should be able to write at least some basic mockups... – Kweamod Feb 7 '14 at 22:09
  • 1
    Well, we're trying to work as a single team. But I guess my question is how do we define roles in this team? Interested to know actually how others define roles. The "UX guy" we hired is super helpful in brainstorming but not terribly good at producing things. – ProgrammerYearningToBePretty Feb 7 '14 at 22:44
1

Your problem seems to be, how to organize the creation of the frontend-part of a website.

Web development projects should base on the same principles like "traditional" software engineering. With that idea in your mind you should first rework your requirements and determine every possible use case and exception, etc. I think, requirements engineering is the most important but at the same time the most underrated part in webdevelopment!

I strongly advise you to hire a person to do the design first, instead of letting your coders decide, which color to use etc, because that is not an effective way to develop your product. The designer creates the layout according to the wireframes of your UX-expert (a complete list of requirements should help him to create the wireframes, you shouldn't do that yourself), the CI, icons, graphics and provides a styleguide for colors, fonts, every possible element on your site (i.e. buttons, forms, ...)

If the design/styleguide is ready, your developers will be able to create a clean HTML markup and CSS code (with the use of preprocessors and OO, I prefer to call it code...) without taking any care of design or conceptual concerns.

1

In my experience the phase you're at is where the UX person, the product owner, and the front-end developer hash out the nitty gritty.

To take the case you presented upthread: user-entered text overflows the neat, idealized boxes your UX person created. There are possible technical solutions to this (limit display to x characters and an ellipses, limit display with a 'show more' link, display full text but expand box horizontally to fit, etc.) but each has different implications for the user experience and some may be untenable given the domain (ie. can't truncate because people often input multiple columns with a tacked-on identifier: "Part Numbers For Widget 1230-A", "Part Numbers For Widget 1230-B" ...).

Together this team can figure out what solutions are possible, what compromises can be made, and generally how best to serve the end user. Working through all this is where UX rubber meets the UX road. Managing edge cases and a wide range of content is a big part of what a good UX person can do for you.

I'm curious what your high-level wireframe is like. You say that you added "too many buttons/checkboxes" and now it looks cluttered. Do the wireframes not account for your buttons and checkboxes?

Also, while I'm glad to see your UX person has given you some valuable insight, this:

He's shown no interest in looking at the extensive sample data I've shared, and has come up with something that is both ugly and doesn't really cover the range of use-cases that we face.

... is a not a great UX person. At the least, he's not what you need now.

1

I'd focus less on dividing up the tasks and more on just getting a good team together.

An ideal UX team (IMO) doesn't have compartmentalized roles but, rather, works together along with the business owner and the development team.

So, what are the tasks that are needed? Off the top of my head, likely:

  • visual design/branding
  • ui design/interaction design
  • IA/flows/wireframing
  • content authoring (and often missed item)
  • analysis/testing/research
  • front end development

That may be 6 people. It may be 1 person. More than likely it'll be 2 or 3 people.

As much as you can, have those people working together rather than independently or in a phased approach.

Another challenge you might be facing is having a development team that has both an interest in and the ability to create a quality front end. I know it's stereotyping a bit, but in my experience, most java developers have zero interest in things like HTML and CSS let along JavaScript. They are focused on the back and and the extent of their front end work consists of whatever drag-n-drop controls the IDE provides them.

This is often the biggest hurdle. The solution is going to be finding a skilled front end dev that is equally comfortable and concerned with the UX as much as they are comfortable and concerned working with the back end teams.

Good luck!

0

Tl;dr: My answer to everything you've asked is "test it".

If you need to redo the interface, you should re-evaluate the whole user experience, not just colors and words.

Start by looking at existing successful products that culturally match your target audience: if it's a bookkeeping system, perhaps you look at QuickBooks. If your product is a plug-in for another existing framework, start with that framework. You should try to understand the product's appeal to your audience. What gender are your typical users? Are they educated or trained differently than you were? Are they from the same culture as you, or are they recent immigrants? Your users will likely have a different set of preferences that you won't or can't fully understand, and you have to at least accept that or you'll end up alienating them.

Next, shop for a designer who has a portfolio that includes an interface that you like, and that you find similar to the successful product. It has to be something you personally find both visually appealing as well as something you consider functional. Explain how you see your relationship working, and what you plan to have him or her do: they get to do an initial blue sky vision, but they then have to integrate it with your existing product, under your direction. Establish the terms of the contract up front to avoid disappointment: you have final authority over the UI, you'll pay X for intermediate work products, etc.

Have the designer start with your use cases. Don't just hand him or her your product and say "improve it", instead, give them the initial opportunity to come up with a vision.

Now it's time for the designer to demo their initial interpretation. Have the designer produce a mockup of a few screen flows that meet a couple of the use cases. It's important that you refrain from being critical at this stage. You might also want to mock-up the same use cases with your existing screens. Bring them both into your usability lab (a conference room with a closed door and a web cam will work), and have a few carefully chosen test subjects evaluate it. Your testers should include at least three people (six would be better); include at least one with no experience on your product, one with novice exposure to it, and someone who has experience. Pick people representative of the culture of your typical users. Have half of them try the new interface first, and half try the old interface first. Interview them and write up their observations of both. Ask them which interface they prefer, and why. Ask if they found any aspect of either of them uncomfortable or offensive. And be sure to reward each of them something for their trouble: a gift certificate worth about two meals (plus drinks) to a decent restaurant is often appropriate for a couple hours of effort, and word of mouth will help you get more volunteers later.

At this point you should have a pretty good idea of whether or not your designer's ideas are worth exploring. The important thing now is that you listen to the feedback from your testers. Try to remember that as they represent your actual customers and users, their opinion on matters of taste are more important than yours.

(Of course, you might find that the new design is so far in opposition to your product and your tastes that there can be no agreement. If so, this may be where you part ways amicably.)

Now it's time to create a "more working" prototype, and for the designer to incorporate your existing data into their use cases. The prototype doesn't have to be functional, but it should navigate the screens appropriately.

This next step depends on if your product is a business application or a "fun" application. For a business app where the typical users are paid by the hour, consider running another usability test. You want a setup where you can measure the average time it takes a user to complete a use case, complete with simulated delays for system processing. Compare that to the time it takes a user of your current system to complete the same use case. If you are selling this to a business, it's important that you don't negatively impact productivity: few customers will want to pay for an upgrade that slows down their data entry people.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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