In the previous post we discussed a host of different things to introduce everyone to the LOB Chronicles project as well as the technologies (both Microsoft and Telerik) that are involved. With a combination of Silverlight, TeamPulse (build with the Telerik Xaml tools), RadControls for Silverlight, OpenAccess, and Test Studio, we’re ready to start planning out our application from the ground up. Before we write code, though, we want to take a step back and consider just who we’re designing this software for - which is where our UX experts come into play.
This is a great question and one which many people (myself included) don’t entirely understand. Thankfully I’m working with two folks who excel with UX practices and theory, so I have been able to seriously improve my understanding of this process. To paraphrase from the recent lesson on UX that I received, UX isn’t about the design of software (although UX recommendations will lead to design choices) but instead concerned with identifying the most high-traffic areas of the application and to devise “a navigation model that will allow the user to both intuitively and quickly reach their destination and perform the actions they have in mind” (quoting one of our UX masters, Kalin).
In looking at John the sales person, we have to examine his primary concern and the goal he is essentially constantly working towards - ‘How do I meet my quota?’ With this in mind, our exploration into UX will dive into the considerations around this one driving goal and how it impacts the daily workflow of a sales person, what concerns he might have around reaching the quota, what information we need to surface quickly and easily to help achieve this goal, and when all is said and done to ensure the software that we are developing here helps, rather than hinders, him achieving this goal. After all, how many times have you blamed bad software (whether it was legitimate or not :D) for having a bad day at work or losing a deal because XYZ screen keeps crashing and you can’t access certain information?
Empathizing With the End User
If we were to put all of the concerns that John has into a diagram, it might look something like the following:
Diving a little further into the nodes here (since there is a lot of information), we know that John is experiencing some of the following…
- You need to bring performance up
- Our competitors are winning deals over us
- Sales aren’t hitting their goals this month
So now John thinks:
- There goes the family pool (no bonus)
- I don’t want to get fired (how will I make the car payments?)
- I might need to find a babysitter (so I can work overtime)
Now John is feeling:
- Impatient (these deals need to close!)
- Lost (how can I fix this?)
Meaning his response to his boss/the team is that John needs to:
- Work to close deals faster
- Surface better opportunities
- Keep better track of deals which might develop into something more
All leading to John spending more time on:
- Pushing to close more opportunities
- Examining possible sales for further engagement
- Monitoring all leads that come in
- Prioritizing customers based on who will likely buy
Turning Empathy into Requirements
As we all know very well, all software has very black and white requirements for what needs to be involved (I need an entry screen, some way to view and browse records, etc.), but by performing this type of UX analysis we can better understand what drives the user and therefore paint those requirements into software that will help the user to accomplish his goals in a much more productive manner.
If we take a closer look at the analysis that we did above, a few key points can be extracted which will help us move onto the next stage of development – working on a UI/navigation model to begin development around. A few key items we might want to include based on our diagram above are:
- Floating opportunities to the top. John always needs to be aware of which opportunities are hot as well as which ones have potential so he can better focus his time.
- Adding and editing contacts and their respective companies. These are key elements to the application since opportunities flow from contacts and companies, so it should be fairly obvious and intuitive to perform these operations.
- Presenting relevant data first. Rather than having to carefully sort, filter, and cross-cut data, John wants to see what is important first and then have the ability to further dive into the data if he needs specifics or is searching for more information.
- Making search work. Searching is another key requirement when working with this type of data. John never wants to be put into a situation where he can remember talking to someone about a deal that has to close by this Friday but cannot remember who, so a viable search solution would allow him to quickly look through records and notes.
- Dashboard – of course. The term ‘dashboards’ may seem overused in LOB development today, but there is a reason for that. We are surrounded by more information than we can process at any given time, so a well-designed dashboard can instead be thought of as a mission control panel that surfaces the most relevant and important information first, letting John know exactly where things stand at a quick glance.
The Next Episode
Before this post we had an understanding of the technologies involved in this project as well as a bit of the process, but now that UX has done a bit of legwork we can better understand how to structure our project and the resulting software in a way that will better help the intended user to accomplish his job.
This ideally means a more productive user leading to more sales, a holiday bonus, happy bosses, and better profits for the company overall. Moving beyond this discussion, next week we will begin to explore how the work UX does can lead to UI implementation. This will cover what screens we might need to help John with his day-to-day activities as well as a navigation model that will allow him to move through the software in the most efficient manner possible. Stay tuned for more!