I am assigned to a huge project as a ux design intern, currently this project doesn't have any documentation. And apparently anyone in the project doesn't know 100% of logic and domain of the system except for senior people. my senior wants me to learn all the things within 1 week of time. is there any quick method to do this?

  • What's your role in the team ? what methodology is your team following ? how big is the project ? what's deliverable your team expected from you after one 1 week ?. For now, you may check design sprint, understand how you can plan a user-research , understanding of the problem, the context, the environment , target audience.Please share more information. Dec 18, 2016 at 12:13
  • thanks for your response. our client has three major products. even though I had a senior ux person and I am an intern one project is handled by me. previously i used to do only the HTML/CSS part, but now ux related decision making is also a part of my job. we are following agile methodology. actually this project is in a working state and I will be working on adding new features, changes and stuff. it is basically a document management system provided by a government with millions of users. currently they don't have any design related document, not even a persona.
    – user92695
    Dec 18, 2016 at 12:56
  • I am assuming you want to start identifying the usability issue on the current system ? so that you and your team will redesign and adding more functionality and feature based on the result of user research and usability testing, is that what the objectives are ? Dec 18, 2016 at 13:58
  • yeah, exactly. And also they are expecting to add an e commerce system to the existing site.
    – user92695
    Dec 18, 2016 at 15:22
  • 1
    You cannot do much for 1 week. UX is a whole discipline with a lot of principles and dependencies. If they want you to do this for 1 week, they should not expect great outcome. Ask for more time because you will not be able to produce quality work. Dec 19, 2016 at 10:35

5 Answers 5


First you must stay as naïve as you can possibly be while you sit down with the system as it is and exercise it without recourse to documentation.

Exercise all of its functions, to the extent that you can figure out what they are. Do the exercising systematically, and take copious notes about the difficulties you encounter, no matter what they are or how easy they are to get past. What were you looking for, what did you find, how did you expect it to work and why, how did it actually work, and how hard was it to rewind your mistakes and escape back to where you were before you inadvertently pulled away the support holding up the roof.

You're basically trying to write the story of a fully-naïve but intelligent customer who believes that how to use some piece of software should be discoverable without documentation and without breaking anything, and what happened when s/he met the software.

When you've done that, get the documentation and do it all again, but this time using the documentation. What role does the documentation play? Is it trying to make up for things that the software itself should make obvious but doesn't? Is it basically a reference manual, a tutorial, a marketing document, or something else? Is it patchy and uneven, showing that too little time was given the writer(s)? Is it confusing? Is it accurate? Is it complete?

When you've done that, you'll have made yourself a virtual customer, and be able to work from that standpoint. But continue to stay naïve if you possibly can, because gaining expertise is a one-way street. Once you're an expert, you'll forget how it was to be a novice and you'll no longer be able to find problems that novices find.


Your overall strategy should be to be curious, ask a lot of questions from different stakeholders in the company and how they work with the product. find out how these people contribute to the product. and their day to day work with the product.

In terms of the product itself, put yourself in the shoes of a user and use the product(s) thoroughly. Do it as a completely new user who as well as an experienced power user. This will help you to come up with flows for each product. when using it, make as much mistakes as possible to identify how the product handles errors and edge cases. also use all the features in various combinations. document all these features.

As you do these a lot of questions and improvements will come to your mind. voice them out and document them.


I tend to agree with Ameen, stakeholders have the info, even if no one stakeholder has it all. The 2 most important stakeholders for you are the Product Owner and the Business Analyst. If this is an existing solution then you could cheat and ask the UX who architected it. If it's a solution that's only just being designed then a good UX speaks to every department and stakeholder and aggregates and consolidates insight. I assure you, most stakeholders will have different ideas on what the solution is designed to do and how it works - actually, that's one of the reasons you need a good UX, to find and join up all the dots. Once you're happy with what you've been told, the and only then, look at the solution design and see if it fulfills your newly acquired expectations


It sounds like the system is large enough that you can't learn about the entire thing. I'd suggest you prioritize. Start with the primary user tasks. What's the main reason for people to use your system? What's secondary? Focus on the features that support those tasks.

Hopefully your seniors can give you that info. Another good way to discover how people are using the system is to talk with your Analytics folks.

Good luck.


In your situation, I would do the following :

  • Read @MMacD answer, as he highlighted important tips and ideas that you should consider when you are analyzing the current system ( Formative evaluation ).
  • I advice you to bring all your stakeholders and plan a user research - You might find this tool useful " This tool was introduced by Tomer Sharon" - The rainbow spreadsheet . This might take a long time depending on the participants to be involved in the research. Meanwhile and since the product exist, I recommend to do a usability test ( from this test you will evaluate the usability issues,efficiency, effectiveness and satisfaction of the current system) additionally, you can include sus to test overall acceptance of the system. U will learn alot about why/where/how you can improve the experience of the current system.
  • Once you have all the data " Usability testing result, the users observation, frustrations and the user research will unveil some important factors, user's goals, the demographics, cultural norms and other things to take in consideration when you and your team going to design/redesign the current system.

This is basically based on Test, build, measure, repeat. If you still want to learn more you can check the following link also you might watch " Sprint-design by GV " it might help you to do a quick and fast lean user experience with your team.

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.