Design ConsultationOOUXUX / UI

The School of Real World UX, OOUX and how to design within limitations.

This is the story of  how UX helped me, a Project Manager and our client to solidify the vision for a product. The interesting factor was the series of events that occurred, which revealed the importance of UX and it’s application in a real life project. I will not disclose which company this was for or details of the project itself, since it’s not important. What is important, is the user experience we were building together.

It all started with a client meeting at their company’s location. It was a very lean team. There was a Project Manager, myself, who was hired as a UX/UI Lead and an offsite Dev Person working on the backend integration. We were attending the kickoff meeting. The Client wanted us to design an Intelligence Tool that gathered data from different users that would turn into analysis that was corroborated. For a moment there, I cringed, how often does one use the word “corroborated” anyway? I personally had never used it before.

As I sat there trying to make sense of their overall idea, I couldn’t help but notice how the the client was referring to intelligence gathering as if he were referring to the CIA which included complex terms, layers of data analysis with different names, and words I had never heard of before. Moreover, the client was insisting we stick to the concept of a pyramid which meant that the intelligence had to be divided into 4 different faces of the pyramid. I admire a challenging concept, but it was a mess and we had only 2 weeks before the first delivery with the client.

I thought to myself, “How am I going to translate this into UX for gathering data, and how will we apply this concept to a web app?”

I braced myself and began. I asked everyone as many questions as possible at that meeting and started identifying the underlying issues right away.

UX is about asking as many questions as possible. Every answer will lead you closer to what's not working. Click To Tweet

The first thing that bothered me most of all was, the Project Manager was identifying the documents and the analysis that we were building, as assets. To me these were two completely different objects. I decided to start the UX Process immediately to explore issues further. I acted according to this great OOUX (Object Oriented UX) workflow I  have learned.

The fastest way to get out of confusing project specs using OOUX is to describe the problem in one paragraph. Click To Tweet

Step 1:  I described the problem in one paragraph.

Step 2: I looked at my paragraph and stripped out all the objects/ nouns and all behaviors / interactions between those objects.

Step 3: I connected the objects and their behaviors in the object mapping diagram.

Celero-Object-Mapping-Diagram

This coining of the problem proved that the term, assets, was not working and we needed to change this terminology asap. A conversation with an offsite developer confirmed my issues. We proposed to split up assets into Content and Analysis. Once the Content (Documents) get added to prove or disprove an Analysis then it became Corroborated. Aha, we were making progress.

OOUX was really helpful in seeing these drawbacks. We kept reworking the terminology to simplify it even further since we were still having problems with the term Analysis and how to place it into the system. We kept researching and stuck with Documents and Hypothesis.

The next step was to work on User Roles and the application flow diagram. For that I utilized LucidChart  and created 4 different user roles with names and company titles. I captured their interactions with the app. I answered questions such as: What would be the first screen they see? What would be their allowed inputs? How would they be able to corroborate on a hypothesis? That is when it started to become clearer. The whole picture was building itself out after a few iterations and check ups with the Project Manger.

Lucid-Chart

Lastly, we nailed the user roles and the application flow diagrams. I was ready to start designing the wireframes and for this I used, UXPin. Here was what I did wrong: I started creating beautiful wireframes for the offsite Developer who was going to start laying out the app features that I designed. I made a most common mistake I got lost in the UI aspect of the app trying to push the envelope of a simple data gathering app. There were cutting edge design elements, transitions and slick form elements. We had about a week left before the first checkpoint with the client. I spent few days on my wireframes.

UXPin-Interface This is what the developer told me after reviewing  my beautiful wireframes, he said it cold and directly,

“Please stop designing those beautiful wireframes, I won’t need them.” I sunk and asked, “Why?”

He answered, “Because we have already selected this API solution and all those features you are so freely creating will not be possible to implement in the amount of time we have. We have to go with what we have.” My rebellious attitude wanted to fight for a better system upgrade, or a better developer, but it was what it was. We had about 3 days left and the developer started laying out the first user screen. I felt dumbfounded, like a splash of cold water had been thrown on the face.

The developer continued, “All I need are blocks of data on the page and how those blocks are talking to each other.”

Say Wow Media - simple wireframe

Sometimes what the developer needs and what you think he needs are two different things. Click To Tweet

I quickly stopped designing my beautiful wireframes and followed the developer’s lead. With the Project Manager we redesigned all the screens into simplified pages with simple blocks that replicated the flow we had captured in the application flow diagram. We submitted them and it finally worked. The developer was happy, the Project Manager was happy and when we took that prototype to the client, the client was also happy to deliver this new solution we were working on, to his peers. I sat back and thought for a moment I was overthinking the deliverables, it was much simpler than I originally thought.

The Moral of the story is:

The strength of a well executed UX is to know the limitations of the system you are designing for. Click To Tweet

UX Saved the day and I got a beautiful THANK YOU email from a Project Manager.

I was happy. UX school Rocked!

Previous post

PERISCOPE - Live Broadcasting App

Next post

Vision Boards, Mind Maps & The Subconscious Mind