UNSPLASH.ME/ALEKS DOROHOVICH

7 Things To Prepare For As An Interaction Designer In Enterprise Software

Designing software that’s intuitive and user centric can be a daunting task when faced with all the pressures and challenges surrounding a large Fortune 500 company, especially when you’re the sole business analyst and user experience advocate on your team

Dan Simerman
5 min readJun 27, 2013

--

1) You may never actually meet the business user you’re designing for

Meeting with users can be a struggle for many reasons. Whether it be logistical, a lack of time and proper planning, or just a bad case of office politics, it’s not always easy to get a sense of who you’re building your application for. Oftentimes, requirements must be gathered from one or two stakeholders designated to represent a wide range of users, and it’s quite possible that their input will be based on their own understanding of the project and not necessarily what is required by the user.

What you can do about it

Develop a relationship with stakeholders early on.

Even if you never get the chance to meet with business stakeholders in person, it’s important you to talk with them directly rather than indirectly through an intermediary or a host of ineffective communication tools. If it’s within the project budget, try suggesting a two or three day ‘onsite’ where stakeholders from across the country (or world) can meet face to face and talk high level scope and strategy. In later stages of the project when stress is mounting, you’ll feel comfortable knowing that that ‘remote worker’ is actually a human being who you share a common goal with.

2) You may not even be designing something anyone wants to use

Have you ever been put into a situation where you were asked to design a product for a task people loath? It can be tough to say the least. The payoff is that you have the opportunity to re-conceptualize a dreaded task in such a way that leaves your client touched, moved and inspired. An interaction designers dream! It sounds like a noble goal, but…

3) You might not even be designing an application for the reason you think

A lot of back room discussions go on in an enterprise environment, many of which you won’t be privy to. That being said, I urge you to break out your James Bond skills and learn exactly WHY this software is in development. Is it because your client wants to optimize for a new line of business? Are regulators breathing down the organization’s back? Does the client just need a better tool to get their work done? Knowing WHY the organization wants something developed will greatly impact WHO you design for. Spoiler: It might not always be the person you think.

What you can do about it

Be candid and ask around. Get the full picture as to why the software was commissioned.

This might take some finesse, but do your best to gather bits and pieces before inquiring to a co-worker or manager. It should be easy to validate a hunch if you put together most of the puzzle yourself. Start a discussion with your co-workers and get a feel for if it’s appropriate to have a conversation with the project manager on your team. If you think office politics are getting in the way, try this exercise: lay out all the user types (personas) you’ve amassed and assign a ranking based on how you perceive the business is prioritizing each group. Do some internal validation and check with the rest of your team - chances are the group assigned the highest number will need to be your main point of focus if you’re intention is to design a balanced user experience. Armed with this information, you should be able to prioritize requirements while staying considerate of all the different user types that must be accounted for.

4) No one takes you seriously

Offering your unique perspective will not always be easy. Developers will believe your input to be superfluous, your team won’t understand how it fits into their workflow, and the stakeholder will summon the long lost ghost of a RiSD graduate just in time to argue with you.

What you can do about it

Be the interaction design evangelist for your project.

Sitting with your team and discussing your thought process could be a good first step in creating an understanding around your ideas. If there’s a new interaction or design element you want to implement, try walking over to your business partner or developer and breaking it down for them. Remember, interaction design is a relatively new field, and it’s quite possible that the people you work with have never even heard of it.

5) Developers might decide on a technology way before you have a set of requirements

You are at the mercy of the tools your developers pick before you even have a chance to create your first persona.

What you can do about it

Ask to be included in technology sizing and budgeting meetings.

You may get scoffed at, but it’ll give you a well-rounded understanding of why certain technologies are going to be used for your project. Injecting yourself into this process early will positively impact your ability to coordinate design efforts later on. If you know a tool won’t meet the needs of the business, it’s better to bring it to the attention of development at a point when something can be done about it.

6) ‘Agile’ is an excuse to do it later

In this environment, design is an afterthought slapped onto the product once wireframes are signed off on by the business. Because interface development is usually lumped together with visual design, your input will generally be seen as unnecessary or a waste of time. Discussing strategy when its most appropriate (early on) will be met with complaints that your bringing up a topic too detailed for whatever part of the software development lifecycle you happen to be in.

What you can do about it

Beats me. Got any ideas?

7) Whether it be a user’s technological strength or weakness, either one may be used against you

Suggest an innovative idea from your favorite design site?

‘Our users are still using Netscape! There’s no way they’ll be able to understand that!!’

Suggest an alternative to an idea proposed by the team?

‘These guys are pretty intuitive; they should be able to figure it out after a few tries. Worse comes to worse, we educate through documentation.’

What you can do about it

A strange phenomenon takes place when you work in software - everyone is an expert on user behavior when it’s convenient for them. How can one manage this effectively? Get answers directly from users. Create a direct line to the people in your organization responsible for using the finished product and get their feedback in realtime. It’ll save countless hours arguing over a design decision or business requirement.

--

--

Dan Simerman

Design, psychology and research oriented product manager @Skookum