Let The UX Process Flow Smooth

QArea Expert by QArea Expert on September 24, 2014

Let The UX Process Flow Smooth
Reading Time: 4 minutes

Every process is unique… Or is it?

Every single person with even a bit of experience in his backpack has found his favorite strategies to do this or to implement that. Everybody has some things to his personal likings and preferences in user experience design. And all the processes are and differ from one another even if it’s a slight tiny difference. But if we’ll be talking in general we will all have but 3 steps for everything related to the subject matter:

  1. Do some researching
  2. Craft sweet prototypes (several is preferred)
  3. Show them to whoever needed like the stakeholders or users or whoever you are having contracts with as long as it’s not the Devil. Not the best dude to have contracts with and rumor says it that he cheats. As do some stakeholders. So be warned.

Despite the seemingly simple procedure of delivering your amazing (as all of them are exquisite and classy and whatever awesome adjective comes to your minds) ideas it is always a bit different as was mentioned in the first sentences of this post. And, despite all your skills, experience, and level of awesomeness there will be a moment when all you’ll be able to say is mere ‘WOW!’ and sometimes you’ll just go to have multiple (like a lot) drinks in complete science. It is indeed our daily life and, as all of us know, ‘stuff’ happens.

So what are the most common of the uncommon issues that will eventually come across your journey to fame and glory of the ultimate designer/developer/paste in your profession? From my experience the further part will pretty much be useful in offshore web development more than everywhere else. Yet is still great with any kinds of projects.

What’s usually going on?

Let’s imagine that we are dealing with a larger project than a simple website as we often are facing such exact projects and with the fast-growing Internet life does not seem to get easier to anybody but the user. It is reasonable to divide and conquer with larger projects. Thus many of you will begin straight from defining some personas and mapping out the journeys of your users. That is splendid. But what if the project is so hardcore you are getting lost in user maps yourself? And you are still to ‘show-&-tell’ all that stuff to your Devils stakeholders. That may indeed bring some uncertainty to the projects very feasibility.

And that may happen in practically any more or less up-to-date web app that may contain as much of them workflows that are catering to users of many various roles inside the system, as the amount of flees on a wild raccoon. Or there are activities multiple users can work with at the same time. That may turn out as a complete mess of total mayhem and destruction. The good old divide and conquer will work here as well. With squeaking and foul language yet it will. Pieces of the puzzle will be feasible as we all know them well. Pieces like the registration form or the logging in part, etc.

So basically you are wireframing with logical steps a user may take from the landing page and straight forward to the goal. You are doing a lot of hard work and hard work takes lots and more of time and do you know that feeling when you are looking at something truly magnificent, a masterpiece of web design, a creation of God himself and you are realizing its way to ambitious to meet the business requirements (or, at least the cash those cheap nice people are willing to pay). And all that effort is suddenly lost.

What should have been done?

You always start with the challenging part. That saves time and effort. You are having the discovery phase within every single project of yours, right? Then put some effort into actual analysis and identify the UI parts that are the toughest of nuts to crack (or twist if necessary) and then begin with crafting wireframes for those parts only. This fits perfectly in any slot of any step of practically any UX practice that is related to mapping out journeys ant types of users.

That is how you know exactly how much (or at least some actual data you may rely on) development time you will require and, as an addition such an approach will make the designing process itself quite easier and faster. I believe an example is really needed were with all that said above. So here we go.

Just imagine you are developing a website. That sounds usual enough, right? And it will have a unique feature (well, at least the paying part is finding it unique and we are to be nice with guys that own our salaries) such as the ability of users to invite friends and to share an activity the site provides. Let’s say they are capable of creating an internet mem all together with some basic yet sweet looking design options. What will the journey be?

  • Login – that’s easy
  • My Mems – pretty basic
  • New mem creation – OK
  • Sending invitations to friends – still easy
  • Awaiting the actual response from them – everything’s smooth here
  • The actual design process along with friends – Bingo! That’s where the actual mass may take place
  • Place it on, let’s say Facebook – we are back with the usual

And now we’ve found the part that seems the most challenging one. We do know that pretty much all the parts will be quite feasible and appropriate as they always are. Nothing new here thus there’s no need to worry about presenting them to stakeholders. But having a bunch of young Mem creators working together at the same time, WOW that will be a mess. That’s why prototyping this piece of the puzzle is what you are to begin with. If you are sure you won’t be able to do it or it will turn out way to expensive suggest some alternatives. And hence this is almost the final step imagine all the time and effort you’ve saved. You are welcome.